9dd5e808 | 07-Mar-2024 |
Eric Auger <eric.auger@redhat.com> |
virtio-iommu: Change the default granule to the host page size
We used to set the default granule to 4KB but with VFIO assignment it makes more sense to use the actual host page size.
Indeed when h
virtio-iommu: Change the default granule to the host page size
We used to set the default granule to 4KB but with VFIO assignment it makes more sense to use the actual host page size.
Indeed when hotplugging a VFIO device protected by a virtio-iommu on a 64kB/64kB host/guest config, we current get a qemu crash:
"vfio: DMA mapping failed, unable to continue"
This is due to the hot-attached VFIO device calling memory_region_iommu_set_page_size_mask() with 64kB granule whereas the virtio-iommu granule was already frozen to 4KB on machine init done.
Set the granule property to "host" and introduce a new compat. The page size mask used before 9.0 was qemu_target_page_mask(). Since the virtio-iommu currently only supports x86_64 and aarch64, this matched a 4KB granule.
Note that the new default will prevent 4kB guest on 64kB host because the granule will be set to 64kB which would be larger than the guest page size. In that situation, the virtio-iommu driver fails on viommu_domain_finalise() with "granule 0x10000 larger than system page size 0x1000".
In that case the workaround is to request 4K granule.
The current limitation of global granule in the virtio-iommu should be removed and turned into per domain granule. But until we get this upgraded, this new default is probably better because I don't think anyone is currently interested in running a 4KB page size guest with virtio-iommu on a 64KB host. However supporting 64kB guest on 64kB host with virtio-iommu and VFIO looks a more important feature.
Signed-off-by: Eric Auger <eric.auger@redhat.com> Reviewed-by: Philippe Mathieu-Daudé <philmd@linaro.org> Reviewed-by: Zhenzhong Duan <zhenzhong.duan@intel.com> Message-Id: <20240307134445.92296-4-eric.auger@redhat.com> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
show more ...
|
0a5b5acd | 08-Mar-2024 |
Ankit Agrawal <ankita@nvidia.com> |
hw/acpi: Implement the SRAT GI affinity structure
ACPI spec provides a scheme to associate "Generic Initiators" [1] (e.g. heterogeneous processors and accelerators, GPUs, and I/O devices with integr
hw/acpi: Implement the SRAT GI affinity structure
ACPI spec provides a scheme to associate "Generic Initiators" [1] (e.g. heterogeneous processors and accelerators, GPUs, and I/O devices with integrated compute or DMA engines GPUs) with Proximity Domains. This is achieved using Generic Initiator Affinity Structure in SRAT. During bootup, Linux kernel parse the ACPI SRAT to determine the PXM ids and create a NUMA node for each unique PXM ID encountered. Qemu currently do not implement these structures while building SRAT.
Add GI structures while building VM ACPI SRAT. The association between device and node are stored using acpi-generic-initiator object. Lookup presence of all such objects and use them to build these structures.
The structure needs a PCI device handle [2] that consists of the device BDF. The vfio-pci device corresponding to the acpi-generic-initiator object is located to determine the BDF.
[1] ACPI Spec 6.3, Section 5.2.16.6 [2] ACPI Spec 6.3, Table 5.80
Cc: Jonathan Cameron <qemu-devel@nongnu.org> Cc: Alex Williamson <alex.williamson@redhat.com> Cc: Cedric Le Goater <clg@redhat.com> Reviewed-by: Jonathan Cameron <Jonathan.Cameron@huawei.com> Signed-off-by: Ankit Agrawal <ankita@nvidia.com> Message-Id: <20240308145525.10886-3-ankita@nvidia.com> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
show more ...
|
c08da86d | 14-Feb-2024 |
Lukas Stockner <lstockner@genesiscloud.com> |
pcie: Support PCIe Gen5/Gen6 link speeds
This patch extends the PCIe link speed option so that slots can be configured as supporting 32GT/s (Gen5) or 64GT/s (Gen5) speeds. This is as simple as setti
pcie: Support PCIe Gen5/Gen6 link speeds
This patch extends the PCIe link speed option so that slots can be configured as supporting 32GT/s (Gen5) or 64GT/s (Gen5) speeds. This is as simple as setting the appropriate bit in LnkCap2 and the appropriate value in LnkCap and LnkCtl2.
Signed-off-by: Lukas Stockner <lstockner@genesiscloud.com> Message-Id: <20240215012326.3272366-1-lstockner@genesiscloud.com> Reviewed-by: Manos Pitsidianakis <manos.pitsidianakis@linaro.org> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
show more ...
|
7e52d0b7 | 12-Mar-2024 |
Peter Maydell <peter.maydell@linaro.org> |
Merge tag 'nvme-next-pull-request' of https://gitlab.com/birkelund/qemu into staging
hw/nvme updates
# -----BEGIN PGP SIGNATURE----- # # iQEzBAABCgAdFiEEUigzqnXi3OaiR2bATeGvMW1PDekFAmXwj+wACgkQTeGv
Merge tag 'nvme-next-pull-request' of https://gitlab.com/birkelund/qemu into staging
hw/nvme updates
# -----BEGIN PGP SIGNATURE----- # # iQEzBAABCgAdFiEEUigzqnXi3OaiR2bATeGvMW1PDekFAmXwj+wACgkQTeGvMW1P # DelOsAf+Jg51zf3vtWpe4MS/WtULjSr5GtnXMJ5hkHS0WdKOiLW3P+pUZXbsohmh # faVlYeCWptF1CFGfxBf4Trc7XzJy8J6W1YJEofs/07hIAnazo9pwk5shoVu4oiex # HVsBg7/9y7DuiEEg1MRvVvW895cP60WmG1AqU63SYwrVgxZ51ZH0XNuyRhQeYC/6 # OSXJ3FDYu2iJQ58uEzGEwv8vhskIpEFTdz0J6gQVxIdzFBbuk87VgZo6pqwgfMBm # /65K85TgFBT4SASc7a2iSUv+iAqSCA6Jdy0VWxCYCikiv5nuPCMCrlbvqcVp+i2B # GKtgfFXhtgepxx6jmYd03EkRjCrxUA== # =W3gg # -----END PGP SIGNATURE----- # gpg: Signature made Tue 12 Mar 2024 17:25:00 GMT # gpg: using RSA key 522833AA75E2DCE6A24766C04DE1AF316D4F0DE9 # gpg: Good signature from "Klaus Jensen <its@irrelevant.dk>" [full] # gpg: aka "Klaus Jensen <k.jensen@samsung.com>" [full] # Primary key fingerprint: DDCA 4D9C 9EF9 31CC 3468 4272 63D5 6FC5 E55D A838 # Subkey fingerprint: 5228 33AA 75E2 DCE6 A247 66C0 4DE1 AF31 6D4F 0DE9
* tag 'nvme-next-pull-request' of https://gitlab.com/birkelund/qemu: hw/nvme: add machine compatibility parameter to enable msix exclusive bar hw/nvme: generalize the mbar size helper hw/nvme: Add NVMe NGUID property MAINTAINERS: add Jesper as reviewer on hw/nvme hw/nvme: fix invalid check on mcl hw/nvme: separate 'serial' property for VFs
Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
show more ...
|
e692f9c6 | 12-Mar-2024 |
Peter Maydell <peter.maydell@linaro.org> |
Merge tag 'pull-request-2024-03-12' of https://gitlab.com/thuth/qemu into staging
* Add missing ERRP_GUARD() statements in functions that need it * Prefer fast cpu_env() over slower CPU QOM cast mac
Merge tag 'pull-request-2024-03-12' of https://gitlab.com/thuth/qemu into staging
* Add missing ERRP_GUARD() statements in functions that need it * Prefer fast cpu_env() over slower CPU QOM cast macro
# -----BEGIN PGP SIGNATURE----- # # iQJFBAABCAAvFiEEJ7iIR+7gJQEY8+q5LtnXdP5wLbUFAmXwPhYRHHRodXRoQHJl # ZGhhdC5jb20ACgkQLtnXdP5wLbWHvBAAgKx5LHFjz3xREVA+LkDTQ49mz0lK3s32 # SGvNlIHjiaDGVttVYhVC4sinBWUruG4Lyv/2QN72OJBzn6WUsEUQE3KPH1d7Y3/s # wS9X7mj70n4kugWJqeIJP5AXSRasHmWoQ4QJLVQRJd6+Eb9jqwep0x7bYkI1de6D # bL1Q7bIfkFeNQBXaiPWAm2i+hqmT4C1r8HEAGZIjAsMFrjy/hzBEjNV+pnh6ZSq9 # Vp8BsPWRfLU2XHm4WX0o8d89WUMAfUGbVkddEl/XjIHDrUD+Zbd1HAhLyfhsmrnE # jXIwSzm+ML1KX4MoF5ilGtg8Oo0gQDEBy9/xck6G0HCm9lIoLKlgTxK9glr2vdT8 # yxZmrM9Hder7F9hKKxmb127xgU6AmL7rYmVqsoQMNAq22D6Xr4UDpgFRXNk2/wO6 # zZZBkfZ4H4MpZXbd/KJpXvYH5mQA4IpkOy8LJdE+dbcHX7Szy9ksZdPA+Z10hqqf # zqS13qTs3abxymy2Q/tO3hPKSJCk1+vCGUkN60Wm+9VoLWGoU43qMc7gnY/pCS7m # 0rFKtvfwFHhokX1orK0lP/ppVzPv/5oFIeK8YDY9if+N+dU2LCwVZHIuf2/VJPRq # wmgH2vAn3JDoRKPxTGX9ly6AMxuZaeP92qBTOPap0gDhihYzIpaCq9ecEBoTakI7 # tdFhV0iRr08= # =NiP4 # -----END PGP SIGNATURE----- # gpg: Signature made Tue 12 Mar 2024 11:35:50 GMT # gpg: using RSA key 27B88847EEE0250118F3EAB92ED9D774FE702DB5 # gpg: issuer "thuth@redhat.com" # gpg: Good signature from "Thomas Huth <th.huth@gmx.de>" [full] # gpg: aka "Thomas Huth <thuth@redhat.com>" [full] # gpg: aka "Thomas Huth <huth@tuxfamily.org>" [full] # gpg: aka "Thomas Huth <th.huth@posteo.de>" [unknown] # Primary key fingerprint: 27B8 8847 EEE0 2501 18F3 EAB9 2ED9 D774 FE70 2DB5
* tag 'pull-request-2024-03-12' of https://gitlab.com/thuth/qemu: (55 commits) user: Prefer fast cpu_env() over slower CPU QOM cast macro target/xtensa: Prefer fast cpu_env() over slower CPU QOM cast macro target/tricore: Prefer fast cpu_env() over slower CPU QOM cast macro target/sparc: Prefer fast cpu_env() over slower CPU QOM cast macro target/sh4: Prefer fast cpu_env() over slower CPU QOM cast macro target/rx: Prefer fast cpu_env() over slower CPU QOM cast macro target/ppc: Prefer fast cpu_env() over slower CPU QOM cast macro target/openrisc: Prefer fast cpu_env() over slower CPU QOM cast macro target/nios2: Prefer fast cpu_env() over slower CPU QOM cast macro target/mips: Prefer fast cpu_env() over slower CPU QOM cast macro target/microblaze: Prefer fast cpu_env() over slower CPU QOM cast macro target/m68k: Prefer fast cpu_env() over slower CPU QOM cast macro target/loongarch: Prefer fast cpu_env() over slower CPU QOM cast macro target/i386/hvf: Use CPUState typedef target/hexagon: Prefer fast cpu_env() over slower CPU QOM cast macro target/cris: Prefer fast cpu_env() over slower CPU QOM cast macro target/avr: Prefer fast cpu_env() over slower CPU QOM cast macro target/alpha: Prefer fast cpu_env() over slower CPU QOM cast macro target: Replace CPU_GET_CLASS(cpu -> obj) in cpu_reset_hold() handler bulk: Call in place single use cpu_env() ...
Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
show more ...
|
fa905f65 | 10-Mar-2024 |
Klaus Jensen <k.jensen@samsung.com> |
hw/nvme: add machine compatibility parameter to enable msix exclusive bar
Commit 1901b4967c3f ("hw/block/nvme: move msix table and pba to BAR 0") moved the MSI-X table and PBA to BAR 0 to make room
hw/nvme: add machine compatibility parameter to enable msix exclusive bar
Commit 1901b4967c3f ("hw/block/nvme: move msix table and pba to BAR 0") moved the MSI-X table and PBA to BAR 0 to make room for enabling CMR and PMR at the same time. As reported by Julien Grall in #2184, this breaks migration through system hibernation.
Add a machine compatibility parameter and set it on machines pre 6.0 to enable the old behavior automatically, restoring the hibernation migration support.
Cc: qemu-stable@nongnu.org Resolves: https://gitlab.com/qemu-project/qemu/-/issues/2184 Fixes: 1901b4967c3f ("hw/block/nvme: move msix table and pba to BAR 0") Reported-by: Julien Grall julien@xen.org Tested-by: Julien Grall julien@xen.org Reviewed-by: Jesper Wendel Devantier <foss@defmacro.it> Signed-off-by: Klaus Jensen <k.jensen@samsung.com>
show more ...
|
fe6d4434 | 12-Mar-2024 |
Peter Maydell <peter.maydell@linaro.org> |
Merge tag 'hw-misc-20240312' of https://github.com/philmd/qemu into staging
Misc HW patch queue
- Rename hw/ide/ahci-internal.h for consistency (Zoltan) - More convenient PCI hotplug trace events (
Merge tag 'hw-misc-20240312' of https://github.com/philmd/qemu into staging
Misc HW patch queue
- Rename hw/ide/ahci-internal.h for consistency (Zoltan) - More convenient PCI hotplug trace events (Vladimir) - Short CLI option to add drives for sam460ex machine (Zoltan) - More missing ERRP_GUARD() macros (Zhao) - Avoid faulting when unmapped I/O BAR is accessed on SPARC EBUS (Mark) - Remove unused includes in hw/core/ (Zhao) - New PCF8574 GPIO over I2C model (Dmitriy) - Require ObjC on Darwin macOS by default (Peter) - Corrected "-smp parameter=1" placement in docs/ (Zhao)
# -----BEGIN PGP SIGNATURE----- # # iQIzBAABCAAdFiEE+qvnXhKRciHc/Wuy4+MsLN6twN4FAmXwEJkACgkQ4+MsLN6t # wN4A3hAAngVu7VmyrfqYF6jfDMUuRGYaKf4D73/KF6R1PsU+nJdN7UAkECLj8o7g # mkcAQu1U3fKCUssF6MJ2a3kU+rD1OkkA/ZcitzgWwEjCK8KVjtMt2HzEqX+B/X+e # RUVjXMOMkyV48MF0+yLhJz+lQiDpEBFVxIgssPBNUz1Pw9IfoXp29Bfz+bYBThS4 # ywAdvCefNzSira0Nt6RWTnvgBHB/1+aLy1uMSt0Xu926zcqoxQJ0b//0flYL8vAf # JuSSZuiXPw+oAc3qG3d6aPl3g8DrFn3pvPD471KlFQAnB0dlhEZZqNBPvraySpHl # h04Y8teHYj9XfxPtaWfaEdgQCazdkKFR/q7E5c9GU00Rf469BJeuo9Pzkm4kWfbU # sbCl8em5biVZ5DpBIOMT3/D0JOyGf7/CM8y5c3Jc92hapx2NdSszkvCicrDE1+i0 # zEr4N0P/F2x5KFVFkQ3Xzv2Jtzw+iXj6kSE5a5/64GMK29Mqu/EPaSkvwGDQOs3N # QJ9mpa4gg47g310a0/nH0i5eVbvGVuzcCMP6VXOBVr18cJ7JFQFFiYcvoTDXNQ2m # sq5xUelRimnWfKpawomJXkS+/j0usH61/aQBuDKfj45i8/XFRejCIk0gMWQ9hjyD # no1HqDN8CVXtiPNSinC7ctNHU5ClS0xO/BRl0h3PGC7Bl+A2eVY= # =JQg1 # -----END PGP SIGNATURE----- # gpg: Signature made Tue 12 Mar 2024 08:21:45 GMT # gpg: using RSA key FAABE75E12917221DCFD6BB2E3E32C2CDEADC0DE # gpg: Good signature from "Philippe Mathieu-Daudé (F4BUG) <f4bug@amsat.org>" [full] # Primary key fingerprint: FAAB E75E 1291 7221 DCFD 6BB2 E3E3 2C2C DEAD C0DE
* tag 'hw-misc-20240312' of https://github.com/philmd/qemu: docs/about/deprecated.rst: Move SMP configurations item to system emulator section meson.build: Always require an objc compiler on macos hosts hw/gpio: introduce pcf8574 driver hw/core: Cleanup unused included headers in numa.c hw/core: Cleanup unused included header in machine-qmp-cmds.c hw/core: Cleanup unused included headers in cpu-common.c sun4u: remap ebus BAR0 to use unassigned_io_ops instead of alias to PCI IO space hw/misc/ivshmem: Fix missing ERRP_GUARD() for error_prepend() hw/core/qdev-properties-system: Fix missing ERRP_GUARD() for error_prepend() hw/core/loader-fit: Fix missing ERRP_GUARD() for error_prepend() hw/ppc/sam460ex: Support short options for adding drives hw/pci: add some convenient trace-events for pcie and shpc hotplug hw/ide/ahci: Rename ahci_internal.h to ahci-internal.h
Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
show more ...
|
97e03106 | 29-Jan-2024 |
Philippe Mathieu-Daudé <philmd@linaro.org> |
hw/core: Declare CPUArchId::cpu as CPUState instead of Object
Do not accept any Object for CPUArchId::cpu field, restrict it to CPUState type.
Signed-off-by: Philippe Mathieu-Daudé <philmd@linaro.o
hw/core: Declare CPUArchId::cpu as CPUState instead of Object
Do not accept any Object for CPUArchId::cpu field, restrict it to CPUState type.
Signed-off-by: Philippe Mathieu-Daudé <philmd@linaro.org> Message-ID: <20240129164514.73104-3-philmd@linaro.org> Reviewed-by: Thomas Huth <thuth@redhat.com> Signed-off-by: Thomas Huth <thuth@redhat.com>
show more ...
|
2ea09fe8 | 11-Mar-2024 |
Zhao Liu <zhao1.liu@intel.com> |
hw/core: Cleanup unused included headers in numa.c
Remove unused header in numa.c: * qemu/bitmap.h * migration/vmstate.h
Note: Though parse_numa_hmat_lb() has the variable named "bitmap_copy", it d
hw/core: Cleanup unused included headers in numa.c
Remove unused header in numa.c: * qemu/bitmap.h * migration/vmstate.h
Note: Though parse_numa_hmat_lb() has the variable named "bitmap_copy", it doesn't use the normal bitmap ops so that it's safe to exclude qemu/bitmap.h header.
Tested by "./configure" and then "make".
Signed-off-by: Zhao Liu <zhao1.liu@intel.com> Reviewed-by: Philippe Mathieu-Daudé <philmd@linaro.org> Message-ID: <20240311075621.3224684-4-zhao1.liu@linux.intel.com> Signed-off-by: Philippe Mathieu-Daudé <philmd@linaro.org>
show more ...
|
5585b026 | 11-Mar-2024 |
Zhao Liu <zhao1.liu@intel.com> |
hw/core: Cleanup unused included header in machine-qmp-cmds.c
Remove unused header (qemu/main-loop.h) in machine-qmp-cmds.c.
Tested by "./configure" and then "make".
Signed-off-by: Zhao Liu <zhao1
hw/core: Cleanup unused included header in machine-qmp-cmds.c
Remove unused header (qemu/main-loop.h) in machine-qmp-cmds.c.
Tested by "./configure" and then "make".
Signed-off-by: Zhao Liu <zhao1.liu@intel.com> Reviewed-by: Philippe Mathieu-Daudé <philmd@linaro.org> Message-ID: <20240311075621.3224684-3-zhao1.liu@linux.intel.com> Signed-off-by: Philippe Mathieu-Daudé <philmd@linaro.org>
show more ...
|
2ed22b2c | 11-Mar-2024 |
Zhao Liu <zhao1.liu@intel.com> |
hw/core: Cleanup unused included headers in cpu-common.c
Remove unused headers in cpu-common.c: * qemu/notify.h * exec/cpu-common.h * qemu/error-report.h * qemu/qemu-print.h
Tested by "./configure"
hw/core: Cleanup unused included headers in cpu-common.c
Remove unused headers in cpu-common.c: * qemu/notify.h * exec/cpu-common.h * qemu/error-report.h * qemu/qemu-print.h
Tested by "./configure" and then "make".
Signed-off-by: Zhao Liu <zhao1.liu@intel.com> Reviewed-by: Philippe Mathieu-Daudé <philmd@linaro.org> Message-ID: <20240311075621.3224684-2-zhao1.liu@linux.intel.com> Signed-off-by: Philippe Mathieu-Daudé <philmd@linaro.org>
show more ...
|
688f2349 | 10-Mar-2024 |
Zhao Liu <zhao1.liu@intel.com> |
hw/core/qdev-properties-system: Fix missing ERRP_GUARD() for error_prepend()
As the comment in qapi/error, passing @errp to error_prepend() requires ERRP_GUARD():
* = Why, when and how to use ERRP_
hw/core/qdev-properties-system: Fix missing ERRP_GUARD() for error_prepend()
As the comment in qapi/error, passing @errp to error_prepend() requires ERRP_GUARD():
* = Why, when and how to use ERRP_GUARD() = * * Without ERRP_GUARD(), use of the @errp parameter is restricted: ... * - It should not be passed to error_prepend(), error_vprepend() or * error_append_hint(), because that doesn't work with &error_fatal. * ERRP_GUARD() lifts these restrictions. * * To use ERRP_GUARD(), add it right at the beginning of the function. * @errp can then be used without worrying about the argument being * NULL or &error_fatal.
ERRP_GUARD() could avoid the case when @errp is &error_fatal, the user can't see this additional information, because exit() happens in error_setg earlier than information is added [1].
The set_chr() passes @errp to error_prepend() without ERRP_GUARD().
As a PropertyInfo.set method, there are too many possible callers to check the impact of this defect; it may or may not be harmless. Thus it is necessary to protect @errp with ERRP_GUARD().
To avoid the issue like [1] said, add missing ERRP_GUARD() at the beginning of this function.
[1]: Issue description in the commit message of commit ae7c80a7bd73 ("error: New macro ERRP_GUARD()").
Cc: Paolo Bonzini <pbonzini@redhat.com> Cc: "Daniel P. Berrangé" <berrange@redhat.com Cc: Eduardo Habkost <eduardo@habkost.net> Signed-off-by: Zhao Liu <zhao1.liu@intel.com> Reviewed-by: Markus Armbruster <armbru@redhat.com> Message-ID: <20240311033822.3142585-16-zhao1.liu@linux.intel.com> Signed-off-by: Philippe Mathieu-Daudé <philmd@linaro.org>
show more ...
|
bfd65b4b | 10-Mar-2024 |
Zhao Liu <zhao1.liu@intel.com> |
hw/core/loader-fit: Fix missing ERRP_GUARD() for error_prepend()
As the comment in qapi/error, passing @errp to error_prepend() requires ERRP_GUARD():
* = Why, when and how to use ERRP_GUARD() = *
hw/core/loader-fit: Fix missing ERRP_GUARD() for error_prepend()
As the comment in qapi/error, passing @errp to error_prepend() requires ERRP_GUARD():
* = Why, when and how to use ERRP_GUARD() = * * Without ERRP_GUARD(), use of the @errp parameter is restricted: ... * - It should not be passed to error_prepend(), error_vprepend() or * error_append_hint(), because that doesn't work with &error_fatal. * ERRP_GUARD() lifts these restrictions. * * To use ERRP_GUARD(), add it right at the beginning of the function. * @errp can then be used without worrying about the argument being * NULL or &error_fatal.
ERRP_GUARD() could avoid the case when @errp is &error_fatal, the user can't see this additional information, because exit() happens in error_setg earlier than information is added [1].
In hw/core/loader-fit.c, there are 2 functions passing @errp to error_prepend() without ERRP_GUARD(): - fit_load_kernel() - fit_load_fdt()
Their @errp parameters are both the pointers of the local @err virable in load_fit().
Though they don't cause the issue like [1] said, to follow the requirement of @errp, add missing ERRP_GUARD() at their beginning.
[1]: Issue description in the commit message of commit ae7c80a7bd73 ("error: New macro ERRP_GUARD()").
Cc: Paul Burton <paulburton@kernel.org> Cc: Aleksandar Rikalo <aleksandar.rikalo@syrmia.com> Signed-off-by: Zhao Liu <zhao1.liu@intel.com> Message-ID: <20240311033822.3142585-15-zhao1.liu@linux.intel.com> Signed-off-by: Philippe Mathieu-Daudé <philmd@linaro.org>
show more ...
|
70c25c92 | 11-Mar-2024 |
Hao Xiang <hao.xiang@bytedance.com> |
migration/multifd: Enable multifd zero page checking by default.
1. Set default "zero-page-detection" option to "multifd". Now zero page checking can be done in the multifd threads and this becomes
migration/multifd: Enable multifd zero page checking by default.
1. Set default "zero-page-detection" option to "multifd". Now zero page checking can be done in the multifd threads and this becomes the default configuration. 2. Handle migration QEMU9.0 -> QEMU8.2 compatibility. We provide backward compatibility where zero page checking is done from the migration main thread.
Signed-off-by: Hao Xiang <hao.xiang@bytedance.com> Reviewed-by: Fabiano Rosas <farosas@suse.de> Reviewed-by: Peter Xu <peterx@redhat.com> Link: https://lore.kernel.org/r/20240311180015.3359271-7-hao.xiang@linux.dev Signed-off-by: Peter Xu <peterx@redhat.com>
show more ...
|
303e6f54 | 11-Mar-2024 |
Hao Xiang <hao.xiang@bytedance.com> |
migration/multifd: Implement zero page transmission on the multifd thread.
1. Add zero_pages field in MultiFDPacket_t. 2. Implements the zero page detection and handling on the multifd threads for n
migration/multifd: Implement zero page transmission on the multifd thread.
1. Add zero_pages field in MultiFDPacket_t. 2. Implements the zero page detection and handling on the multifd threads for non-compression, zlib and zstd compression backends. 3. Added a new value 'multifd' in ZeroPageDetection enumeration. 4. Adds zero page counters and updates multifd send/receive tracing format to track the newly added counters.
Signed-off-by: Hao Xiang <hao.xiang@bytedance.com> Acked-by: Markus Armbruster <armbru@redhat.com> Reviewed-by: Fabiano Rosas <farosas@suse.de> Link: https://lore.kernel.org/r/20240311180015.3359271-5-hao.xiang@linux.dev Signed-off-by: Peter Xu <peterx@redhat.com>
show more ...
|
5fdbb1df | 11-Mar-2024 |
Hao Xiang <hao.xiang@bytedance.com> |
migration/multifd: Add new migration option zero-page-detection.
This new parameter controls where the zero page checking is running. 1. If this parameter is set to 'legacy', zero page checking is d
migration/multifd: Add new migration option zero-page-detection.
This new parameter controls where the zero page checking is running. 1. If this parameter is set to 'legacy', zero page checking is done in the migration main thread. 2. If this parameter is set to 'none', zero page checking is disabled.
Signed-off-by: Hao Xiang <hao.xiang@bytedance.com> Reviewed-by: Peter Xu <peterx@redhat.com> Acked-by: Markus Armbruster <armbru@redhat.com> Link: https://lore.kernel.org/r/20240311180015.3359271-4-hao.xiang@linux.dev Signed-off-by: Peter Xu <peterx@redhat.com>
show more ...
|
4503dcf7 | 08-Mar-2024 |
Zhao Liu <zhao1.liu@intel.com> |
hw/core/machine-smp: Calculate total CPUs once in machine_parse_smp_config()
In machine_parse_smp_config(), the number of total CPUs is calculated by:
drawers * books * sockets * dies * cluster
hw/core/machine-smp: Calculate total CPUs once in machine_parse_smp_config()
In machine_parse_smp_config(), the number of total CPUs is calculated by:
drawers * books * sockets * dies * clusters * cores * threads
To avoid missing the future new topology level, use a local variable to cache the calculation result so that total CPUs are only calculated once.
Signed-off-by: Zhao Liu <zhao1.liu@intel.com> Reviewed-by: Philippe Mathieu-Daudé <philmd@linaro.org> Message-ID: <20240308160148.3130837-4-zhao1.liu@linux.intel.com> Signed-off-by: Philippe Mathieu-Daudé <philmd@linaro.org>
show more ...
|
54c4ea8f | 08-Mar-2024 |
Zhao Liu <zhao1.liu@intel.com> |
hw/core/machine-smp: Deprecate unsupported "parameter=1" SMP configurations
Currently, it was allowed for users to specify the unsupported topology parameter as "1". For example, x86 PC machine does
hw/core/machine-smp: Deprecate unsupported "parameter=1" SMP configurations
Currently, it was allowed for users to specify the unsupported topology parameter as "1". For example, x86 PC machine doesn't support drawer/book/cluster topology levels, but user could specify "-smp drawers=1,books=1,clusters=1".
This is meaningless and confusing, so that the support for this kind of configurations is marked deprecated since 9.0. And report warning message for such case like:
qemu-system-x86_64: warning: Deprecated CPU topology (considered invalid): Unsupported clusters parameter mustn't be specified as 1 qemu-system-x86_64: warning: Deprecated CPU topology (considered invalid): Unsupported books parameter mustn't be specified as 1 qemu-system-x86_64: warning: Deprecated CPU topology (considered invalid): Unsupported drawers parameter mustn't be specified as 1
Users have to ensure that all the topology members described with -smp are supported by the target machine.
Signed-off-by: Zhao Liu <zhao1.liu@intel.com> Reviewed-by: Thomas Huth <thuth@redhat.com> Message-ID: <20240308160148.3130837-3-zhao1.liu@linux.intel.com> Signed-off-by: Philippe Mathieu-Daudé <philmd@linaro.org>
show more ...
|
72d346f3 | 08-Mar-2024 |
Zhao Liu <zhao1.liu@intel.com> |
hw/core/machine-smp: Remove deprecated "parameter=0" SMP configurations
The "parameter=0" SMP configurations have been marked as deprecated since v6.2.
For these cases, -smp currently returns the w
hw/core/machine-smp: Remove deprecated "parameter=0" SMP configurations
The "parameter=0" SMP configurations have been marked as deprecated since v6.2.
For these cases, -smp currently returns the warning and adjusts the zeroed parameters to 1 by default.
Remove the above compatibility logic in v9.0, and return error directly if any -smp parameter is set as 0.
Signed-off-by: Zhao Liu <zhao1.liu@intel.com> Reviewed-by: Thomas Huth <thuth@redhat.com> Reviewed-by: Prasad Pandit <pjp@fedoraproject.org> Message-ID: <20240308160148.3130837-2-zhao1.liu@linux.intel.com> Signed-off-by: Philippe Mathieu-Daudé <philmd@linaro.org>
show more ...
|
965bc083 | 27-Feb-2024 |
Eric Auger <eric.auger@redhat.com> |
qdev: Add a granule_mode property
Introduce a new enum type property allowing to set an IOMMU granule. Values are 4k, 8k, 16k, 64k and host. This latter indicates the vIOMMU granule will match the h
qdev: Add a granule_mode property
Introduce a new enum type property allowing to set an IOMMU granule. Values are 4k, 8k, 16k, 64k and host. This latter indicates the vIOMMU granule will match the host page size.
A subsequent patch will add such a property to the virtio-iommu device.
Signed-off-by: Eric Auger <eric.auger@redhat.com> Reviewed-by: Zhenzhong Duan <zhenzhong.duan@intel.com> Signed-off-by: Philippe Mathieu-Daudé <philmd@linaro.org> Message-ID: <20240227165730.14099-2-eric.auger@redhat.com>
show more ...
|
c0061471 | 27-Feb-2024 |
Alex Bennée <alex.bennee@linaro.org> |
plugins: create CPUPluginState and migrate plugin_mask
As we expand the per-vCPU data for plugins we don't want to pollute CPUState. For now this just moves the plugin_mask (renamed to event_mask) a
plugins: create CPUPluginState and migrate plugin_mask
As we expand the per-vCPU data for plugins we don't want to pollute CPUState. For now this just moves the plugin_mask (renamed to event_mask) as the memory callbacks are accessed directly by TCG generated code.
Reviewed-by: Pierrick Bouvier <pierrick.bouvier@linaro.org> Signed-off-by: Alex Bennée <alex.bennee@linaro.org> Message-Id: <20240227144335.1196131-23-alex.bennee@linaro.org>
show more ...
|
81cf548f | 27-Feb-2024 |
Pierrick Bouvier <pierrick.bouvier@linaro.org> |
cpu: call plugin init hook asynchronously
This ensures we run during a cpu_exec, which allows to call start/end exclusive from this init hook (needed for new scoreboard API introduced later).
async
cpu: call plugin init hook asynchronously
This ensures we run during a cpu_exec, which allows to call start/end exclusive from this init hook (needed for new scoreboard API introduced later).
async work is run before any tb is translated/executed, so we can guarantee plugin init will be called before any other hook.
The previous change made sure that any idle/resume cb call will not be done before initializing plugin for a given vcpu.
Reviewed-by: Richard Henderson <richard.henderson@linaro.org> Signed-off-by: Pierrick Bouvier <pierrick.bouvier@linaro.org> Message-Id: <20240213094009.150349-5-pierrick.bouvier@linaro.org> Signed-off-by: Alex Bennée <alex.bennee@linaro.org> Message-Id: <20240227144335.1196131-20-alex.bennee@linaro.org>
show more ...
|
ee59fa1d | 27-Feb-2024 |
Akihiko Odaki <akihiko.odaki@daynix.com> |
gdbstub: Simplify XML lookup
Now we know all instances of GDBFeature that is used in CPU so we can traverse them to find XML. This removes the need for a CPU-specific lookup function for dynamic XML
gdbstub: Simplify XML lookup
Now we know all instances of GDBFeature that is used in CPU so we can traverse them to find XML. This removes the need for a CPU-specific lookup function for dynamic XMLs.
Signed-off-by: Akihiko Odaki <akihiko.odaki@daynix.com> Reviewed-by: Alex Bennée <alex.bennee@linaro.org> Message-Id: <20231213-gdb-v17-7-777047380591@daynix.com> Signed-off-by: Alex Bennée <alex.bennee@linaro.org> Message-Id: <20240227144335.1196131-12-alex.bennee@linaro.org>
show more ...
|
0441e35f | 20-Feb-2024 |
Peter Maydell <peter.maydell@linaro.org> |
hw/core/machine: Use qemu_register_resettable for sysbus reset
Move the reset of the sysbus (and thus all devices and buses anywhere on the qbus tree) from qemu_register_reset() to qemu_register_res
hw/core/machine: Use qemu_register_resettable for sysbus reset
Move the reset of the sysbus (and thus all devices and buses anywhere on the qbus tree) from qemu_register_reset() to qemu_register_resettable().
This is a behaviour change: because qemu_register_resettable() is aware of three-phase reset, this now means that: * 'enter' phase reset methods of devices and buses are called before any legacy reset callbacks registered with qemu_register_reset() * 'exit' phase reset methods of devices and buses are called after any legacy qemu_register_reset() callbacks
Put another way, a qemu_register_reset() callback is now correctly ordered in the 'hold' phase along with any other 'hold' phase methods.
The motivation for doing this is that we will now be able to resolve some reset-ordering issues using the three-phase mechanism, because the 'exit' phase is always after the 'hold' phase, even when the 'hold' phase function was registered with qemu_register_reset().
Signed-off-by: Peter Maydell <peter.maydell@linaro.org> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Reviewed-by: Richard Henderson <richard.henderson@linaro.org> Reviewed-by: Philippe Mathieu-Daudé <philmd@linaro.org> Reviewed-by: Daniel P. Berrangé <berrange@redhat.com> Message-id: 20240220160622.114437-10-peter.maydell@linaro.org Reviewed-by: Zhao Liu <zhao1.liu@intel.com>
show more ...
|
71b3ea37 | 20-Feb-2024 |
Peter Maydell <peter.maydell@linaro.org> |
hw/core/reset: Implement qemu_register_reset via qemu_register_resettable
Reimplement qemu_register_reset() via qemu_register_resettable().
We define a new LegacyReset object which implements Reset
hw/core/reset: Implement qemu_register_reset via qemu_register_resettable
Reimplement qemu_register_reset() via qemu_register_resettable().
We define a new LegacyReset object which implements Resettable and defines its reset hold phase method to call a QEMUResetHandler function. When qemu_register_reset() is called, we create a new LegacyReset object and add it to the simulation_reset ResettableContainer. When qemu_unregister_reset() is called, we find the LegacyReset object in the container and remove it.
This implementation of qemu_unregister_reset() means we'll end up scanning the ResetContainer's list of child objects twice, once to find the LegacyReset object, and once in g_ptr_array_remove(). In theory we could avoid this by having the ResettableContainer interface include a resettable_container_remove_with_equal_func() that took a callback method so that we could use g_ptr_array_find_with_equal_func() and g_ptr_array_remove_index(). But we don't expect qemu_unregister_reset() to be called frequently or in hot paths, and we expect the simulation_reset container to usually not have many children.
Signed-off-by: Peter Maydell <peter.maydell@linaro.org> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Reviewed-by: Richard Henderson <richard.henderson@linaro.org> Reviewed-by: Philippe Mathieu-Daudé <philmd@linaro.org> Reviewed-by: Daniel P. Berrangé <berrange@redhat.com> Message-id: 20240220160622.114437-9-peter.maydell@linaro.org Reviewed-by: Zhao Liu <zhao1.liu@intel.com>
show more ...
|