Avoid propagating the clock change when the clock does not change.
Signed-off-by: Philippe Mathieu-Daudé <f4bug@amsat.org>
Reviewed-by: Richard Henderson <richard.henderson@linaro.org>
Message-id: 20200806123858.30058-4-f4bug@amsat.org
Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
Let clock_set() return a boolean value whether the clock
has been updated or not.
Signed-off-by: Philippe Mathieu-Daudé <f4bug@amsat.org>
Reviewed-by: Richard Henderson <richard.henderson@linaro.org>
Message-id: 20200806123858.30058-3-f4bug@amsat.org
Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
clock_init*() inlined funtions are simple wrappers around
clock_set*() and are not used. Remove them in favor of clock_set*().
Signed-off-by: Philippe Mathieu-Daudé <f4bug@amsat.org>
Reviewed-by: Richard Henderson <richard.henderson@linaro.org>
Message-id: 20200806123858.30058-2-f4bug@amsat.org
Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
Fixing a typo in a previous patch that translated an "i" to a 1
and therefore breaking the allocation of PCIe interrupts. This was
discovered when virtio-net-pci devices ceased to function correctly.
Cc: qemu-stable@nongnu.org
Fixes: 48ba18e6d3 ("hw/arm/sbsa-ref: Simplify by moving the gic in the machine state")
Signed-off-by: Graeme Gregory <graeme@nuviainc.com>
Reviewed-by: Philippe Mathieu-Daudé <f4bug@amsat.org>
Message-id: 20200821083853.356490-1-graeme@nuviainc.com
Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
better number of queues for vhost
smbios speed options
acpi fixes
Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
-----BEGIN PGP SIGNATURE-----
iQFDBAABCAAtFiEEXQn9CHHI+FuUyooNKB8NuNKNVGkFAl9HqC0PHG1zdEByZWRo
YXQuY29tAAoJECgfDbjSjVRprQgH/RGhdPuAFbclXkPNjKojv1XJXTSqQbzLgjAt
D5R6lVGJlci7vgqJbBiNPFo7tjbXXIG5k1uVHPRluUQGdu0UR807wvPMObShlBQi
FIhZnaLww2HRYg4qAb8NHz+2BoVJf2uQ+w4Qe+G4Oo9JIg8kYpyVdMwi1yp0q0Op
cXuZ56oWPGBhODB7CUUJ2KI76mInGGkE7Y8FDArBfB7/fZrWnmUW9DDY7xiOGDWk
ewvXVZIktYeSRMZKz03boB+0u+uBrkpr6qzmIp/BqjnwYCrwyUsGaFt2vvI1E1dY
+NMh5rboZecRqV4z58BUDsHe1aQXZVeV37jyh9kqBRArKHK5XNA=
=bE7D
-----END PGP SIGNATURE-----
Merge remote-tracking branch 'remotes/mst/tags/for_upstream' into staging
virtio,pc,acpi: features, fixes
better number of queues for vhost
smbios speed options
acpi fixes
Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
# gpg: Signature made Thu 27 Aug 2020 13:33:49 BST
# gpg: using RSA key 5D09FD0871C8F85B94CA8A0D281F0DB8D28D5469
# gpg: issuer "mst@redhat.com"
# gpg: Good signature from "Michael S. Tsirkin <mst@kernel.org>" [full]
# gpg: aka "Michael S. Tsirkin <mst@redhat.com>" [full]
# Primary key fingerprint: 0270 606B 6F3C DF3D 0B17 0970 C350 3912 AFBE 8E67
# Subkey fingerprint: 5D09 FD08 71C8 F85B 94CA 8A0D 281F 0DB8 D28D 5469
* remotes/mst/tags/for_upstream:
tests/bios-tables-test: add smbios cpu speed test
hw/smbios: add options for type 4 max-speed and current-speed
vhost-user-blk-pci: default num_queues to -smp N
virtio-blk-pci: default num_queues to -smp N
virtio-scsi-pci: default num_queues to -smp N
virtio-scsi: introduce a constant for fixed virtqueues
virtio-pci: add virtio_pci_optimal_num_queues() helper
Introduce a new flag for i440fx to disable PCI hotplug on the root bus
acpi: update expected DSDT files with _UID changes
disassemble-aml: -o actually works
arm/acpi: fix an out of spec _UID for PCI root
i386/acpi: fix inconsistent QEMU/OVMF device paths
acpi: allow DSDT changes
Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
Add smbios type 4 CPU speed check for we added new options to set
smbios type 4 "max speed" and "current speed". The default value
should be 2000 when no option is specified, just as the old version
did.
We add the test case to one machine of each architecture, though it
doesn't really run on aarch64 platform for smbios test can't run on
uefi only platform yet.
Signed-off-by: Ying Fang <fangying1@huawei.com>
Signed-off-by: Heyi Guo <guoheyi@huawei.com>
Message-Id: <20200806035634.376-3-fangying1@huawei.com>
Common VM users sometimes care about CPU speed, so we add two new
options to allow VM vendors to present CPU speed to their users.
Normally these information can be fetched from host smbios.
Strictly speaking, the "max speed" and "current speed" in type 4
are not really for the max speed and current speed of processor, for
"max speed" identifies a capability of the system, and "current speed"
identifies the processor's speed at boot (see smbios spec), but some
applications do not tell the differences.
Reviewed-by: Igor Mammedov <imammedo@redhat.com>
Signed-off-by: Ying Fang <fangying1@huawei.com>
Signed-off-by: Heyi Guo <guoheyi@huawei.com>
Message-Id: <20200806035634.376-2-fangying1@huawei.com>
Automatically size the number of request virtqueues to match the number
of vCPUs. This ensures that completion interrupts are handled on the
same vCPU that submitted the request. No IPI is necessary to complete
an I/O request and performance is improved. The maximum number of MSI-X
vectors and virtqueues limit are respected.
Signed-off-by: Stefan Hajnoczi <stefanha@redhat.com>
Reviewed-by: Cornelia Huck <cohuck@redhat.com>
Reviewed-by: Raphael Norwitz <raphael.norwitz@nutanix.com>
Message-Id: <20200818143348.310613-8-stefanha@redhat.com>
Reviewed-by: Michael S. Tsirkin <mst@redhat.com>
Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
Automatically size the number of virtio-blk-pci request virtqueues to
match the number of vCPUs. Other transports continue to default to 1
request virtqueue.
A 1:1 virtqueue:vCPU mapping ensures that completion interrupts are
handled on the same vCPU that submitted the request. No IPI is
necessary to complete an I/O request and performance is improved. The
maximum number of MSI-X vectors and virtqueues limit are respected.
Performance improves from 78k to 104k IOPS on a 32 vCPU guest with 101
virtio-blk-pci devices (ioengine=libaio, iodepth=1, bs=4k, rw=randread
with NVMe storage).
Signed-off-by: Stefan Hajnoczi <stefanha@redhat.com>
Reviewed-by: Cornelia Huck <cohuck@redhat.com>
Reviewed-by: Pankaj Gupta <pankaj.gupta.linux@gmail.com>
Message-Id: <20200818143348.310613-7-stefanha@redhat.com>
Reviewed-by: Michael S. Tsirkin <mst@redhat.com>
Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
Automatically size the number of virtio-scsi-pci, vhost-scsi-pci, and
vhost-user-scsi-pci request virtqueues to match the number of vCPUs.
Other transports continue to default to 1 request virtqueue.
A 1:1 virtqueue:vCPU mapping ensures that completion interrupts are
handled on the same vCPU that submitted the request. No IPI is
necessary to complete an I/O request and performance is improved. The
maximum number of MSI-X vectors and virtqueues limit are respected.
Signed-off-by: Stefan Hajnoczi <stefanha@redhat.com>
Message-Id: <20200818143348.310613-6-stefanha@redhat.com>
Reviewed-by: Cornelia Huck <cohuck@redhat.com>
Reviewed-by: Raphael Norwitz <raphael.norwitz@nutanix.com>
Reviewed-by: Michael S. Tsirkin <mst@redhat.com>
Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
The event and control virtqueues are always present, regardless of the
multi-queue configuration. Define a constant so that virtqueue number
calculations are easier to read.
Signed-off-by: Stefan Hajnoczi <stefanha@redhat.com>
Reviewed-by: Cornelia Huck <cohuck@redhat.com>
Reviewed-by: Pankaj Gupta <pankaj.gupta.linux@gmail.com>
Reviewed-by: Philippe Mathieu-Daudé <philmd@redhat.com>
Reviewed-by: Raphael Norwitz <raphael.norwitz@nutanix.com>
Message-Id: <20200818143348.310613-5-stefanha@redhat.com>
Reviewed-by: Michael S. Tsirkin <mst@redhat.com>
Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
Multi-queue devices achieve the best performance when each vCPU has a
dedicated queue. This ensures that virtqueue used notifications are
handled on the same vCPU that submitted virtqueue buffers. When another
vCPU handles the the notification an IPI will be necessary to wake the
submission vCPU and this incurs a performance overhead.
Provide a helper function that virtio-pci devices will use in later
patches to automatically select the optimal number of queues.
The function handles guests with large numbers of CPUs by limiting the
number of queues to fit within the following constraints:
1. The maximum number of MSI-X vectors.
2. The maximum number of virtqueues.
Signed-off-by: Stefan Hajnoczi <stefanha@redhat.com>
Reviewed-by: Cornelia Huck <cohuck@redhat.com>
Message-Id: <20200818143348.310613-4-stefanha@redhat.com>
Reviewed-by: Michael S. Tsirkin <mst@redhat.com>
Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
We introduce a new global flag 'acpi-root-pci-hotplug' for i440fx with which
we can turn on or off PCI device hotplug on the root bus. This flag can be
used to prevent all PCI devices from getting hotplugged or unplugged from the
root PCI bus.
This feature is targetted mostly towards Windows VMs. It is useful in cases
where some hypervisor admins want to deploy guest VMs in a way so that the
users of the guest OSes are not able to hot-eject certain PCI devices from
the Windows system tray. Laine has explained the use case here in detail:
https://www.redhat.com/archives/libvir-list/2020-February/msg00110.html
Julia has resolved this issue for PCIE buses with the following commit:
530a096318 ("pcie_root_port: Add hotplug disabling option")
This commit attempts to introduce similar behavior for PCI root buses used in
i440fx machine types (although in this case, we do not have a per-slot
capability to turn hotplug on or off).
Usage:
-global PIIX4_PM.acpi-root-pci-hotplug=off
By default, this option is enabled which means that hotplug is turned on for
the PCI root bus.
The previously existing flag 'acpi-pci-hotplug-with-bridge-support' for PCI-PCI
bridges remain as is and can be used along with this new flag to control PCI
hotplug on PCI bridges.
This change has been tested using a Windows 2012R2 server guest image and also
with a Windows 2019 server guest image on a Ubuntu 18.04 host using the latest
master qemu from upstream.
Signed-off-by: Ani Sinha <ani@anisinha.ca>
Message-Id: <20200821165403.26589-1-ani@anisinha.ca>
Reviewed-by: Michael S. Tsirkin <mst@redhat.com>
Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
Tested-by: Igor Mammedov <imammedo@redhat.com>
Reviewed-by: Igor Mammedov <imammedo@redhat.com>
On ARM/virt machine type QEMU currently reports an incorrect _UID in
ACPI.
The particular node in question is the primary PciRoot (PCI0 in ACPI),
which gets assigned PCI0 in ACPI UID and 0 in the
DevicePath. This is due to the _UID assigned to it by build_dsdt in
hw/arm/virt-acpi-build.c Which does not correspond to the primary PCI
identifier given by pcibus_num in hw/pci/pci.c
In UEFI v2.8, section "10.4.2 Rules with ACPI _HID and _UID" ends with
the paragraph,
Root PCI bridges will use the plug and play ID of PNP0A03, This will
be stored in the ACPI Device Path _HID field, or in the Expanded
ACPI Device Path _CID field to match the ACPI name space. The _UID
in the ACPI Device Path structure must match the _UID in the ACPI
name space.
(See especially the last sentence.)
A similar bug has been reported on i386, on that architecture it has
been reported to confuse at least macOS which uses ACPI UIDs to build
the DevicePath for NVRAM boot options, while OVMF firmware gets them via
an internal channel through QEMU. When UEFI firmware and ACPI have
different values, this makes the underlying operating system unable to
report its boot option.
Cc: qemu-stable@nongnu.org
Reported-by: Vitaly Cheptsov <vit9696@protonmail.com>
Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
Reviewed-by: Laszlo Ersek <lersek@redhat.com>
macOS uses ACPI UIDs to build the DevicePath for NVRAM boot options,
while OVMF firmware gets them via an internal channel through QEMU.
Due to a bug in QEMU ACPI currently UEFI firmware and ACPI have
different values, and this makes the underlying operating system
unable to report its boot option.
The particular node in question is the primary PciRoot (PCI0 in ACPI),
which for some reason gets assigned 1 in ACPI UID and 0 in the
DevicePath. This is due to the _UID assigned to it by build_dsdt in
hw/i386/acpi-build.c Which does not correspond to the primary PCI
identifier given by pcibus_num in hw/pci/pci.c
Reference with the device paths, OVMF startup logs, and ACPI table
dumps (SysReport):
https://github.com/acidanthera/bugtracker/issues/1050
In UEFI v2.8, section "10.4.2 Rules with ACPI _HID and _UID" ends with
the paragraph,
Root PCI bridges will use the plug and play ID of PNP0A03, This will
be stored in the ACPI Device Path _HID field, or in the Expanded
ACPI Device Path _CID field to match the ACPI name space. The _UID
in the ACPI Device Path structure must match the _UID in the ACPI
name space.
(See especially the last sentence.)
Considering *extra* root bridges / root buses (with bus number > 0),
QEMU's ACPI generator actually does the right thing; since QEMU commit
c96d9286a6 ("i386/acpi-build: more traditional _UID and _HID for PXB
root buses", 2015-06-11).
However, the _UID values for root bridge zero (on both i440fx and q35)
have always been "wrong" (from UEFI perspective), going back in QEMU to
commit 74523b8501 ("i386: add ACPI table files from seabios",
2013-10-14).
Even in SeaBIOS, these _UID values have always been 1; see commit
a4d357638c57 ("Port rombios32 code from bochs-bios.", 2008-03-08) for
i440fx, and commit ecbe3fd61511 ("seabios: q35: add dsdt", 2012-12-01)
for q35.
Cc: qemu-stable@nongnu.org
Suggested-by: Laszlo Ersek <lersek@redhat.com>
Tested-by: Vitaly Cheptsov <vit9696@protonmail.com>
Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
Reviewed-by: Laszlo Ersek <lersek@redhat.com>
Booting on s390x is a little bit different compared to other architectures.
Let's add some information for people who are not yet used to this.
Signed-off-by: Thomas Huth <thuth@redhat.com>
Message-Id: <20200806150507.12073-1-thuth@redhat.com>
[CH: minor wording tweaks]
Signed-off-by: Cornelia Huck <cohuck@redhat.com>
-----BEGIN PGP SIGNATURE-----
iHUEABYIAB0WIQS86RI+GtKfB8BJu973ErUQojoPXwUCX0bPowAKCRD3ErUQojoP
X43sAPwP4Prb0NQTw68l5oSwOoIcuWb4GZBjxOPecDis/0K2ogD/WswDJ8qk3RAQ
7XYGY8LuMdhwfcsx15TsuB/HAUie3QM=
=wIGS
-----END PGP SIGNATURE-----
Merge remote-tracking branch 'remotes/hdeller/tags/target-hppa-v3-pull-request' into staging
artist out of bounds fixes
# gpg: Signature made Wed 26 Aug 2020 22:09:55 BST
# gpg: using EDDSA key BCE9123E1AD29F07C049BBDEF712B510A23A0F5F
# gpg: Good signature from "Helge Deller <deller@gmx.de>" [unknown]
# gpg: aka "Helge Deller <deller@kernel.org>" [unknown]
# gpg: WARNING: This key is not certified with a trusted signature!
# gpg: There is no indication that the signature belongs to the owner.
# Primary key fingerprint: 4544 8228 2CD9 10DB EF3D 25F8 3E5F 3D04 A7A2 4603
# Subkey fingerprint: BCE9 123E 1AD2 9F07 C049 BBDE F712 B510 A23A 0F5F
* remotes/hdeller/tags/target-hppa-v3-pull-request:
hw/display/artist: Fix invalidation of lines near screen border
hw/display/artist: Fix invalidation of lines in artist_draw_line()
hw/display/artist: Unbreak size mismatch memory accesses
hw/display/artist: Prevent out of VRAM buffer accesses
Revert "hw/display/artist: Avoid drawing line when nothing to display"
hw/display/artist: Refactor artist_rop8() to avoid buffer over-run
hw/display/artist: Check offset in draw_line to avoid buffer over-run
hw/hppa/lasi: Don't abort on invalid IMR value
hw/display/artist.c: fix out of bounds check
hw/hppa: Implement proper SeaBIOS version check
seabios-hppa: Update to SeaBIOS hppa version 1
hw/hppa: Sync hppa_hardware.h file with SeaBIOS sources
Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
If parts of the invalidated screen lines are outside of the VRAM buffer,
the code skips the whole invalidate. This is incorrect when only parts
of the buffer are invisble - which is the case when the mouse cursor is
located near the screen border.
Signed-off-by: Sven Schnelle <svens@stackframe.org>
Signed-off-by: Helge Deller <deller@gmx.de>
The old code didn't invalidate correctly when vertical lines were drawn.
Fix this and move the invalidation out of the loop.
Signed-off-by: Sven Schnelle <svens@stackframe.org>
Signed-off-by: Helge Deller <deller@gmx.de>
Commit 5d971f9e67 ("memory: Revert "memory: accept mismatching sizes
in memory_region_access_valid") broke the artist driver in a way that
the dtwm window manager on HP-UX rendered wrong.
Fixes: 5d971f9e67 ("memory: Revert "memory: accept mismatching sizes in memory_region_access_valid")
Signed-off-by: Sven Schnelle <svens@stackframe.org>
Signed-off-by: Helge Deller <deller@gmx.de>
Invalid I/O writes can craft an offset out of the vram_buffer range.
Instead of passing an unsafe pointer to artist_rop8(), pass the vram_buffer and
the offset. We can now check if the offset is in range before accessing it.
We avoid:
Program terminated with signal SIGSEGV, Segmentation fault.
284 *dst &= ~plane_mask;
(gdb) bt
#0 0x000056367b2085c0 in artist_rop8 (s=0x56367d38b510, dst=0x7f9f972fffff <error: Cannot access memory at address 0x7f9f972fffff>, val=0 '\000') at hw/display/artist.c:284
#1 0x000056367b209325 in draw_line (s=0x56367d38b510, x1=-20480, y1=-1, x2=0, y2=17920, update_start=true, skip_pix=-1, max_pix=-1) at hw/display/artist.c:646
Reported-by: LLVM libFuzzer
Buglink: https://bugs.launchpad.net/qemu/+bug/1880326
Signed-off-by: Philippe Mathieu-Daudé <f4bug@amsat.org>
Signed-off-by: Helge Deller <deller@gmx.de>
Invalid I/O writes can craft an offset out of the vram_buffer range.
We avoid:
Program terminated with signal SIGSEGV, Segmentation fault.
284 *dst &= ~plane_mask;
(gdb) bt
#0 0x000055d5dccdc5c0 in artist_rop8 (s=0x55d5defee510, dst=0x7f8e84ed8216 <error: Cannot access memory at address 0x7f8e84ed8216>, val=0 '\000') at hw/display/artist.c:284
#1 0x000055d5dccdcf83 in fill_window (s=0x55d5defee510, startx=22, starty=5674, width=65, height=5697) at hw/display/artist.c:551
#2 0x000055d5dccddfb9 in artist_reg_write (opaque=0x55d5defee510, addr=1051140, val=4265537, size=4) at hw/display/artist.c:902
#3 0x000055d5dcb42a7c in memory_region_write_accessor (mr=0x55d5defeea10, addr=1051140, value=0x7ffe57db08c8, size=4, shift=0, mask=4294967295, attrs=...) at memory.c:483
Reported-by: LLVM libFuzzer
Signed-off-by: Philippe Mathieu-Daudé <f4bug@amsat.org>
Signed-off-by: Helge Deller <deller@gmx.de>
NetBSD initializes the LASI IMR value with 0xffffffff to disable all LASI
interrupts. This triggered an assert() and stopped the emulation. By replacing
the check with a warning in the guest log we now allow NetBSD to boot again.
Signed-off-by: Helge Deller <deller@gmx.de>
- qcow2 subclusters (extended L2 entries)
-----BEGIN PGP SIGNATURE-----
iQFGBAABCAAwFiEEkb62CjDbPohX0Rgp9AfbAGHVz0AFAl9GESASHG1yZWl0ekBy
ZWRoYXQuY29tAAoJEPQH2wBh1c9AKNsH/1iG6YVi9c25BoE/3nnu1yJSQiVqpjzt
hRsV0LzqqaUd3r/yLx5wyFpmcOC+iqJsNrrJCMR9GqMCXyOiH2S9xZs9rVnL44dr
gt8bhbAfLTQr6ix9rzJUekRHWa0oeoECS6FLdkAnc6xB5Tf5YwOXdX8FYGiR6M9Q
mibqBIRbQX10ptdZjRpQaDNiTAGMoXfXa1YxTfeFuvW/vwnP34mT+K1B6o1CxDdL
G9mG9atF0Zu5qjovapw0a/lnEppyxIJXSpU0s6s7dGbuAzw8IRM5utJLSNu4hL/c
fTxmAnhcB6bFPaMHHMP4izQFds1M1NBZFX/4ji+u0cE8CgTGSqmupRA=
=j4jq
-----END PGP SIGNATURE-----
Merge remote-tracking branch 'remotes/maxreitz/tags/pull-block-2020-08-26' into staging
Block patches:
- qcow2 subclusters (extended L2 entries)
# gpg: Signature made Wed 26 Aug 2020 08:37:04 BST
# gpg: using RSA key 91BEB60A30DB3E8857D11829F407DB0061D5CF40
# gpg: issuer "mreitz@redhat.com"
# gpg: Good signature from "Max Reitz <mreitz@redhat.com>" [full]
# Primary key fingerprint: 91BE B60A 30DB 3E88 57D1 1829 F407 DB00 61D5 CF40
* remotes/maxreitz/tags/pull-block-2020-08-26: (34 commits)
iotests: Add tests for qcow2 images with extended L2 entries
qcow2: Assert that expand_zero_clusters_in_l1() does not support subclusters
qcow2: Allow preallocation and backing files if extended_l2 is set
qcow2: Add the 'extended_l2' option and the QCOW2_INCOMPAT_EXTL2 bit
qcow2: Add prealloc field to QCowL2Meta
qcow2: Add subcluster support to qcow2_measure()
qcow2: Add subcluster support to qcow2_co_pwrite_zeroes()
qcow2: Add subcluster support to handle_alloc_space()
qcow2: Clear the L2 bitmap when allocating a compressed cluster
qcow2: Update L2 bitmap in qcow2_alloc_cluster_link_l2()
qcow2: Add subcluster support to check_refcounts_l2()
qcow2: Add subcluster support to discard_in_l2_slice()
qcow2: Add subcluster support to zero_in_l2_slice()
qcow2: Add subcluster support to qcow2_get_host_offset()
qcow2: Add subcluster support to calculate_l2_meta()
qcow2: Handle QCOW2_SUBCLUSTER_UNALLOCATED_ALLOC
qcow2: Replace QCOW2_CLUSTER_* with QCOW2_SUBCLUSTER_*
qcow2: Add cluster type parameter to qcow2_get_host_offset()
qcow2: Add qcow2_cluster_is_allocated()
qcow2: Add qcow2_get_subcluster_range_type()
...
Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
Signed-off-by: Alberto Garcia <berto@igalia.com>
Reviewed-by: Max Reitz <mreitz@redhat.com>
Message-Id: <e6dd0429cafe84ca603179c298a8703bddca2904.1594396418.git.berto@igalia.com>
[mreitz: Use env in shebang line]
Signed-off-by: Max Reitz <mreitz@redhat.com>
machines. The Spike and Virt machines both support NUMA sockets.
This PR also updates the current experimental Hypervisor support to the
v0.6.1 spec.
-----BEGIN PGP SIGNATURE-----
iQEzBAABCAAdFiEE9sSsRtSTSGjTuM6PIeENKd+XcFQFAl9FXM0ACgkQIeENKd+X
cFRuPgf6A7yfDjapdHIJlX+wr8O2QEVKSL59+t/TgJRv+0CsmP4MdkYE2g0zA7zy
mstYAgZNXTYE6Ee+WnOLcP7chAsdTjFyAnsUgNOXDToVEQQykm6XdaPsZsRJNnTG
AcAPN6+s9kBvh9NUTfQHb4tEvvD/mGk5wsT58ciYWl8islpCADcYgAtboTSLY/gA
qTex0McllG+y4coJudubi+uv46BeaetgQ59cBb4K65zsSM9fesRz8dUvSyXyFv10
CUFpQLxX410wvBlTV3I5L7bwOT5OdFjw1dzwE6VET+tu9YlLOOHuRuptnDhdTHgu
Dkxx4YB7SRBiF+/JUvxJ559Ez106pw==
=TQFe
-----END PGP SIGNATURE-----
Merge remote-tracking branch 'remotes/alistair/tags/pull-riscv-to-apply-20200825' into staging
This pull request first adds support for multi-socket NUMA RISC-V
machines. The Spike and Virt machines both support NUMA sockets.
This PR also updates the current experimental Hypervisor support to the
v0.6.1 spec.
# gpg: Signature made Tue 25 Aug 2020 19:47:41 BST
# gpg: using RSA key F6C4AC46D4934868D3B8CE8F21E10D29DF977054
# gpg: Good signature from "Alistair Francis <alistair@alistair23.me>" [full]
# Primary key fingerprint: F6C4 AC46 D493 4868 D3B8 CE8F 21E1 0D29 DF97 7054
* remotes/alistair/tags/pull-riscv-to-apply-20200825:
target/riscv: Support the Virtual Instruction fault
target/riscv: Return the exception from invalid CSR accesses
target/riscv: Support the v0.6 Hypervisor extension CRSs
target/riscv: Only support little endian guests
target/riscv: Only support a single VSXL length
target/riscv: Update the CSRs to the v0.6 Hyp extension
target/riscv: Update the Hypervisor trap return/entry
target/riscv: Fix the interrupt cause code
target/riscv: Convert MSTATUS MTL to GVA
target/riscv: Don't allow guest to write to htinst
target/riscv: Do two-stage lookups on hlv/hlvx/hsv instructions
target/riscv: Allow generating hlv/hlvx/hsv instructions
target/riscv: Allow setting a two-stage lookup in the virt status
hw/riscv: virt: Allow creating multiple NUMA sockets
hw/riscv: spike: Allow creating multiple NUMA sockets
hw/riscv: Add helpers for RISC-V multi-socket NUMA machines
hw/riscv: Allow creating multiple instances of PLIC
hw/riscv: Allow creating multiple instances of CLINT
Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
When performing a CSR access let's return a negative exception value on
an error instead of -1. This will allow us to specify the exception in
future patches.
Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
Message-id: a487dad60c9b8fe7a2b992c5e0dcc2504a9000a7.1597259519.git.alistair.francis@wdc.com
Message-Id: <a487dad60c9b8fe7a2b992c5e0dcc2504a9000a7.1597259519.git.alistair.francis@wdc.com>
We extend RISC-V virt machine to allow creating a multi-socket
machine. Each RISC-V virt machine socket is a NUMA node having
a set of HARTs, a memory instance, a CLINT instance, and a PLIC
instance. Other devices are shared between all sockets. We also
update the generated device tree accordingly.
By default, NUMA multi-socket support is disabled for RISC-V virt
machine. To enable it, users can use "-numa" command-line options
of QEMU.
Example1: For two NUMA nodes with 2 CPUs each, append following
to command-line options: "-smp 4 -numa node -numa node"
Example2: For two NUMA nodes with 1 and 3 CPUs, append following
to command-line options:
"-smp 4 -numa node -numa node -numa cpu,node-id=0,core-id=0 \
-numa cpu,node-id=1,core-id=1 -numa cpu,node-id=1,core-id=2 \
-numa cpu,node-id=1,core-id=3"
The maximum number of sockets in a RISC-V virt machine is 8
but this limit can be changed in future.
Signed-off-by: Anup Patel <anup.patel@wdc.com>
Reviewed-by: Atish Patra <atish.patra@wdc.com>
Message-Id: <20200616032229.766089-6-anup.patel@wdc.com>
Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
We extend RISC-V spike machine to allow creating a multi-socket
machine. Each RISC-V spike machine socket is a NUMA node having
a set of HARTs, a memory instance, and a CLINT instance. Other
devices are shared between all sockets. We also update the
generated device tree accordingly.
By default, NUMA multi-socket support is disabled for RISC-V spike
machine. To enable it, users can use "-numa" command-line options
of QEMU.
Example1: For two NUMA nodes with 2 CPUs each, append following
to command-line options: "-smp 4 -numa node -numa node"
Example2: For two NUMA nodes with 1 and 3 CPUs, append following
to command-line options:
"-smp 4 -numa node -numa node -numa cpu,node-id=0,core-id=0 \
-numa cpu,node-id=1,core-id=1 -numa cpu,node-id=1,core-id=2 \
-numa cpu,node-id=1,core-id=3"
The maximum number of sockets in a RISC-V spike machine is 8
but this limit can be changed in future.
Signed-off-by: Anup Patel <anup.patel@wdc.com>
Reviewed-by: Atish Patra <atish.patra@wdc.com>
Message-Id: <20200616032229.766089-5-anup.patel@wdc.com>
Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
We add common helper routines which can be shared by RISC-V
multi-socket NUMA machines.
We have two types of helpers:
1. riscv_socket_xyz() - These helper assist managing multiple
sockets irrespective whether QEMU NUMA is enabled/disabled
2. riscv_numa_xyz() - These helpers assist in providing
necessary QEMU machine callbacks for QEMU NUMA emulation
Signed-off-by: Anup Patel <anup.patel@wdc.com>
Reviewed-by: Atish Patra <atish.patra@wdc.com>
Message-Id: <20200616032229.766089-4-anup.patel@wdc.com>
Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
