aboutsummaryrefslogtreecommitdiff
path: root/hw/core/machine.c
AgeCommit message (Collapse)Author
2024-05-22Merge tag 'migration-20240522-pull-request' of ↵Richard Henderson
https://gitlab.com/farosas/qemu into staging Migration pull request - Li Zhijian's COLO minor fixes - Marc-André's virtio-gpu fix - Fiona's virtio-net USO fix - A couple of migration-test fixes from Thomas # -----BEGIN PGP SIGNATURE----- # # iQJEBAABCAAuFiEEqhtIsKIjJqWkw2TPx5jcdBvsMZ0FAmZObggQHGZhcm9zYXNA # c3VzZS5kZQAKCRDHmNx0G+wxnWE8D/49RGE+g29qyk9aKx3lU8mSq+ZzmX5GncBt # 5+Mx5qoHDsBCQTE+dQpEVIoeMJ2HIbgbOML4qsnp6Hw/4/TWkfwC/R6+ZmHBevRk # fVLkVh2JMHVg8Tq+0FO1X1QnMU03uJ7EAuWdDa8HqlJ5dQY/K3gDaku8oQBXk96X # 13pChSbMob76tdb+wiwbdEakabigH7XfrPdI6lzI8MCGTIcPKc/UKTFYuoj/OsNx # raqy+uBtvKtfHxiaYnIgHIPNAF/1f4tP3iAOcPoZWIMXWxFkE8+ANDJAbWo6xIcL # DGg/wEzZO/OnXLjOhjvLBUHK/fx4wQ5bsqA09BVxoRyBGblkXr+bcwBLYjgiEqzT # aniPiAx5W/Db+T7HqZPIWesFYj3cmcwvYUTrx/RPMdC0epG+ZczDMtescHdZbxvt # Pjs3nFeCLhyYcVhlTI72eXRCxdd/26+r6/OmrBC2+GaZrybM61TvNo+3XvO0Pfhi # UmwF2EN27XmSMelLvH/MnflUVgBHKDs3CCQzDlxreHq2jMVR0SL7LU5wMJJ58Iok # M3u74izQM25bwYxiASH+4iRn0puH1mOwgOx28W0uiQfZY/678/lCnwa1Tul15BRE # fIQZJhyIGzhSpwLqEXmdXdlLQs1isqIgpd/mzKgZ285nLr7kz+4gxCUqiXgVbrl7 # P45Dym1u4g== # =DDrh # -----END PGP SIGNATURE----- # gpg: Signature made Wed 22 May 2024 03:13:28 PM PDT # gpg: using RSA key AA1B48B0A22326A5A4C364CFC798DC741BEC319D # gpg: issuer "farosas@suse.de" # gpg: Good signature from "Fabiano Rosas <farosas@suse.de>" [unknown] # gpg: aka "Fabiano Almeida Rosas <fabiano.rosas@suse.com>" [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: AA1B 48B0 A223 26A5 A4C3 64CF C798 DC74 1BEC 319D * tag 'migration-20240522-pull-request' of https://gitlab.com/farosas/qemu: tests/qtest/migration-test: Fix the check for a successful run of analyze-migration.py tests/qtest/migration-test: Run some basic tests on s390x and ppc64 with TCG, too hw/core/machine: move compatibility flags for VirtIO-net USO to machine 8.1 virtio-gpu: fix v2 migration migration: fix a typo migration: add "exists" info to load-state-field trace migration/colo: Tidy up bql_unlock() around bdrv_activate_all() migration/colo: make colo_incoming_co() return void migration/colo: Minor fix for colo error message Signed-off-by: Richard Henderson <richard.henderson@linaro.org>
2024-05-22hw/core/machine: move compatibility flags for VirtIO-net USO to machine 8.1Fiona Ebner
Migration from an 8.2 or 9.0 binary to an 8.1 binary with machine version 8.1 can fail with: > kvm: Features 0x1c0010130afffa7 unsupported. Allowed features: 0x10179bfffe7 > kvm: Failed to load virtio-net:virtio > kvm: error while loading state for instance 0x0 of device '0000:00:12.0/virtio-net' > kvm: load of migration failed: Operation not permitted The series 53da8b5a99 virtio-net: Add support for USO features 9da1684954 virtio-net: Add USO flags to vhost support. f03e0cf63b tap: Add check for USO features 2ab0ec3121 tap: Add USO support to tap device. only landed in QEMU 8.2, so the compatibility flags should be part of machine version 8.1. Moving the flags unfortunately breaks forward migration with machine version 8.1 from a binary without this patch to a binary with this patch. Fixes: 53da8b5a99 ("virtio-net: Add support for USO features") Signed-off-by: Fiona Ebner <f.ebner@proxmox.com> Reviewed-by: Fabiano Rosas <farosas@suse.de> Acked-by: Jason Wang <jasowang@redhat.com> Reviewed-by: Peter Xu <peterx@redhat.com> Signed-off-by: Fabiano Rosas <farosas@suse.de>
2024-05-22virtio-gpu: fix v2 migrationMarc-André Lureau
Commit dfcf74fa ("virtio-gpu: fix scanout migration post-load") broke forward/backward version migration. Versioning of nested VMSD structures is not straightforward, as the wire format doesn't have nested structures versions. Introduce x-scanout-vmstate-version and a field test to save/load appropriately according to the machine version. Fixes: dfcf74fa ("virtio-gpu: fix scanout migration post-load") Signed-off-by: Marc-André Lureau <marcandre.lureau@redhat.com> Signed-off-by: Peter Xu <peterx@redhat.com> Reviewed-by: Fiona Ebner <f.ebner@proxmox.com> Tested-by: Fiona Ebner <f.ebner@proxmox.com> [fixed long lines] Signed-off-by: Fabiano Rosas <farosas@suse.de>
2024-05-16vfio/pci: migration: Skip config space check for Vendor Specific Information ↵Vinayak Kale
in VSC during restore/load In case of migration, during restore operation, qemu checks config space of the pci device with the config space in the migration stream captured during save operation. In case of config space data mismatch, restore operation is failed. config space check is done in function get_pci_config_device(). By default VSC (vendor-specific-capability) in config space is checked. Due to qemu's config space check for VSC, live migration is broken across NVIDIA vGPU devices in situation where source and destination host driver is different. In this situation, Vendor Specific Information in VSC varies on the destination to ensure vGPU feature capabilities exposed to the guest driver are compatible with destination host. If a vfio-pci device is migration capable and vfio-pci vendor driver is OK with volatile Vendor Specific Info in VSC then qemu should exempt config space check for Vendor Specific Info. It is vendor driver's responsibility to ensure that VSC is consistent across migration. Here consistency could mean that VSC format should be same on source and destination, however actual Vendor Specific Info may not be byte-to-byte identical. This patch skips the check for Vendor Specific Information in VSC for VFIO-PCI device by clearing pdev->cmask[] offsets. Config space check is still enforced for 3 byte VSC header. If cmask[] is not set for an offset, then qemu skips config space check for that offset. VSC check is skipped for machine types >= 9.1. The check would be enforced on older machine types (<= 9.0). Cc: Alex Williamson <alex.williamson@redhat.com> Cc: Michael S. Tsirkin <mst@redhat.com> Cc: Cédric Le Goater <clg@redhat.com> Signed-off-by: Vinayak Kale <vkale@nvidia.com> Reviewed-by: Cédric Le Goater <clg@redhat.com> Signed-off-by: Cédric Le Goater <clg@redhat.com>
2024-05-08migration: Remove non-multifd compressionFabiano Rosas
The 'compress' migration capability enables the old compression code which has shown issues over the years and is thought to be less stable and tested than the more recent multifd-based compression. The old compression code has been deprecated in 8.2 and now is time to remove it. Deprecation commit 864128df46 ("migration: Deprecate old compression method"). Acked-by: Markus Armbruster <armbru@redhat.com> Reviewed-by: Peter Xu <peterx@redhat.com> Signed-off-by: Fabiano Rosas <farosas@suse.de>
2024-04-30target/arm: Default to 1GHz cntfrq for 'max' and new CPUsPeter Maydell
In previous versions of the Arm architecture, the frequency of the generic timers as reported in CNTFRQ_EL0 could be any IMPDEF value, and for QEMU we picked 62.5MHz, giving a timer tick period of 16ns. In Armv8.6, the architecture standardized this frequency to 1GHz. Because there is no ID register feature field that indicates whether a CPU is v8.6 or that it ought to have this counter frequency, we implement this by changing our default CNTFRQ value for all CPUs, with exceptions for backwards compatibility: * CPU types which we already implement will retain the old default value. None of these are v8.6 CPUs, so this is architecturally OK. * CPUs used in versioned machine types with a version of 9.0 or earlier will retain the old default value. The upshot is that the only CPU type that changes is 'max'; but any new type we add in future (whether v8.6 or not) will also get the new 1GHz default. It remains the case that the machine model can override the default value via the 'cntfrq' QOM property (regardless of the CPU type). Signed-off-by: Peter Maydell <peter.maydell@linaro.org> Reviewed-by: Richard Henderson <richard.henderson@linaro.org> Reviewed-by: Philippe Mathieu-Daudé <philmd@linaro.org> Message-id: 20240426122913.3427983-5-peter.maydell@linaro.org
2024-04-25hw/core: Support module-id in numa configurationZhao Liu
Module is a level above the core, thereby supporting numa configuration on the module level can bring user more numa flexibility. This is the natural further support for module level. Add module level support in numa configuration. Tested-by: Yongwei Ma <yongwei.ma@intel.com> Signed-off-by: Zhao Liu <zhao1.liu@intel.com> Tested-by: Babu Moger <babu.moger@amd.com> Message-ID: <20240424154929.1487382-5-zhao1.liu@intel.com> Signed-off-by: Philippe Mathieu-Daudé <philmd@linaro.org>
2024-04-25hw/core/machine: Support modules in -smpZhao Liu
Add "modules" parameter parsing support in -smp. Suggested-by: Xiaoyao Li <xiaoyao.li@intel.com> Tested-by: Yongwei Ma <yongwei.ma@intel.com> Signed-off-by: Zhao Liu <zhao1.liu@intel.com> Tested-by: Babu Moger <babu.moger@amd.com> Acked-by: Markus Armbruster <armbru@redhat.com> Message-ID: <20240424154929.1487382-3-zhao1.liu@intel.com> Signed-off-by: Philippe Mathieu-Daudé <philmd@linaro.org>
2024-04-25hw/core/machine: Introduce the module as a CPU topology levelZhao Liu
In x86, module is the topology level above core, which contains a set of cores that share certain resources (in current products, the resource usually includes L2 cache, as well as module scoped features and MSRs). Though smp.clusters could also share the L2 cache resource [1], there are following reasons that drive us to introduce the new smp.modules: * As the CPU topology abstraction in device tree [2], cluster supports nesting (though currently QEMU hasn't support that). In contrast, (x86) module does not support nesting. * Due to nesting, there is great flexibility in sharing resources on cluster, rather than narrowing cluster down to sharing L2 (and L3 tags) as the lowest topology level that contains cores. * Flexible nesting of cluster allows it to correspond to any level between the x86 package and core. * In Linux kernel, x86's cluster only represents the L2 cache domain but QEMU's smp.clusters is the CPU topology level. Linux kernel will also expose module level topology information in sysfs for x86. To avoid cluster ambiguity and keep a consistent CPU topology naming style with the Linux kernel, we introduce module level for x86. The module is, in existing hardware practice, the lowest layer that contains the core, while the cluster is able to have a higher topological scope than the module due to its nesting. Therefore, place the module between the cluster and the core: drawer/book/socket/die/cluster/module/core/thread With the above topological hierarchy order, introduce module level support in MachineState and MachineClass. [1]: https://lore.kernel.org/qemu-devel/c3d68005-54e0-b8fe-8dc1-5989fe3c7e69@huawei.com/ [2]: https://www.kernel.org/doc/Documentation/devicetree/bindings/cpu/cpu-topology.txt Suggested-by: Xiaoyao Li <xiaoyao.li@intel.com> Tested-by: Yongwei Ma <yongwei.ma@intel.com> Signed-off-by: Zhao Liu <zhao1.liu@intel.com> Tested-by: Babu Moger <babu.moger@amd.com> Message-ID: <20240424154929.1487382-2-zhao1.liu@intel.com> Signed-off-by: Philippe Mathieu-Daudé <philmd@linaro.org>
2024-04-23HostMem: Add mechanism to opt in kvm guest memfd via MachineStateXiaoyao Li
Add a new member "guest_memfd" to memory backends. When it's set to true, it enables RAM_GUEST_MEMFD in ram_flags, thus private kvm guest_memfd will be allocated during RAMBlock allocation. Memory backend's @guest_memfd is wired with @require_guest_memfd field of MachineState. It avoid looking up the machine in phymem.c. MachineState::require_guest_memfd is supposed to be set by any VMs that requires KVM guest memfd as private memory, e.g., TDX VM. Signed-off-by: Xiaoyao Li <xiaoyao.li@intel.com> Reviewed-by: David Hildenbrand <david@redhat.com> Message-ID: <20240320083945.991426-8-michael.roth@amd.com> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2024-04-18hw: Add compat machines for 9.1Paolo Bonzini
Add 9.1 machine types for arm/i440fx/m68k/q35/s390x/spapr. Reviewed-by: Cornelia Huck <cohuck@redhat.com> Acked-by: Thomas Huth <thuth@redhat.com> Reviewed-by: Harsh Prateek Bora <harshpb@linux.ibm.com> Reviewed-by: Zhao Liu <zhao1.liu@intel.com> Cc: Gavin Shan <gshan@redhat.com> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2024-03-13Merge tag 'for_upstream' of https://git.kernel.org/pub/scm/virt/kvm/mst/qemu ↵Peter Maydell
into staging virtio,pc,pci: features, cleanups, fixes more memslots support in libvhost-user support PCIe Gen5/Gen6 link speeds in pcie more traces in vdpa network simulation devices support in vdpa SMBIOS type 9 descriptor implementation Bump max_cpus to 4096 vcpus in q35 aw-bits and granule options in VIRTIO-IOMMU Support report NUMA nodes for device memory using GI in acpi Beginning of shutdown event support in pvpanic fixes, cleanups all over the place. Signed-off-by: Michael S. Tsirkin <mst@redhat.com> # -----BEGIN PGP SIGNATURE----- # # iQFDBAABCAAtFiEEXQn9CHHI+FuUyooNKB8NuNKNVGkFAmXw0TMPHG1zdEByZWRo # YXQuY29tAAoJECgfDbjSjVRp8x4H+gLMoGwaGAX7gDGPgn2Ix4j/3kO77ZJ9X9k/ # 1KqZu/9eMS1j2Ei+vZqf05w7qRjxxhwDq3ilEXF/+UFqgAehLqpRRB8j5inqvzYt # +jv0DbL11PBp/oFjWcytm5CbiVsvq8KlqCF29VNzc162XdtcduUOWagL96y8lJfZ # uPrOoyeR7SMH9lp3LLLHWgu+9W4nOS03RroZ6Umj40y5B7yR0Rrppz8lMw5AoQtr # 0gMRnFhYXeiW6CXdz+Tzcr7XfvkkYDi/j7ibiNSURLBfOpZa6Y8+kJGKxz5H1K1G # 6ZY4PBcOpQzl+NMrktPHogczgJgOK10t+1i/R3bGZYw2Qn/93Eg= # =C0UU # -----END PGP SIGNATURE----- # gpg: Signature made Tue 12 Mar 2024 22:03:31 GMT # 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 * tag 'for_upstream' of https://git.kernel.org/pub/scm/virt/kvm/mst/qemu: (68 commits) docs/specs/pvpanic: document shutdown event hw/cxl: Fix missing reserved data in CXL Device DVSEC hmat acpi: Fix out of bounds access due to missing use of indirection hmat acpi: Do not add Memory Proximity Domain Attributes Structure targetting non existent memory. qemu-options.hx: Document the virtio-iommu-pci aw-bits option hw/arm/virt: Set virtio-iommu aw-bits default value to 48 hw/i386/q35: Set virtio-iommu aw-bits default value to 39 virtio-iommu: Add an option to define the input range width virtio-iommu: Trace domain range limits as unsigned int qemu-options.hx: Document the virtio-iommu-pci granule option virtio-iommu: Change the default granule to the host page size virtio-iommu: Add a granule property hw/i386/acpi-build: Add support for SRAT Generic Initiator structures hw/acpi: Implement the SRAT GI affinity structure qom: new object to associate device to NUMA node hw/i386/pc: Inline pc_cmos_init() into pc_cmos_init_late() and remove it hw/i386/pc: Set "normal" boot device order in pc_basic_device_init() hw/i386/pc: Avoid one use of the current_machine global hw/i386/pc: Remove "rtc_state" link again Revert "hw/i386/pc: Confine system flash handling to pc_sysfw" ... Signed-off-by: Peter Maydell <peter.maydell@linaro.org> # Conflicts: # hw/core/machine.c
2024-03-12hw/i386/q35: Set virtio-iommu aw-bits default value to 39Eric Auger
Currently the default input range can extend to 64 bits. On x86, when the virtio-iommu protects vfio devices, the physical iommu may support only 39 bits. Let's set the default to 39, as done for the intel-iommu. We use hw_compat_8_2 to handle the compatibility for machines before 9.0 which used to have a virtio-iommu default input range of 64 bits. Of course if aw-bits is set from the command line, the default is overriden. Signed-off-by: Eric Auger <eric.auger@redhat.com> Message-Id: <20240307134445.92296-8-eric.auger@redhat.com> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com> Reviewed-by: Zhenzhong Duan <zhenzhong.duan@intel.com>
2024-03-12virtio-iommu: Change the default granule to the host page sizeEric Auger
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>
2024-03-12Merge tag 'nvme-next-pull-request' of https://gitlab.com/birkelund/qemu into ↵Peter Maydell
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>
2024-03-12Merge tag 'pull-request-2024-03-12' of https://gitlab.com/thuth/qemu into ↵Peter Maydell
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>
2024-03-12hw/nvme: add machine compatibility parameter to enable msix exclusive barKlaus Jensen
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>
2024-03-12hw/core: Declare CPUArchId::cpu as CPUState instead of ObjectPhilippe Mathieu-Daudé
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>
2024-03-11migration/multifd: Enable multifd zero page checking by default.Hao Xiang
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>
2024-02-27hw/core/machine: Use qemu_register_resettable for sysbus resetPeter Maydell
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>
2024-01-12numa: Skip invalidation of cluster and NUMA node boundary for qtestGavin Shan
There are warning messages printed from tests/qtest/numa-test.c, to complain the CPU cluster and NUMA node boundary is broken. Since the broken boundary is expected, we don't want to see the warning messages. # cd /home/gavin/sandbox/qemu.main/build # MALLOC_PERTURB_=255 QTEST_QEMU_BINARY=./qemu-system-aarch64 \ G_TEST_DBUS_DAEMON=../tests/dbus-vmstate-daemon.sh \ QTEST_QEMU_IMG=./qemu-img \ QTEST_QEMU_STORAGE_DAEMON_BINARY=./storage-daemon/qemu-storage-daemon \ tests/qtest/numa-test --tap -k : qemu-system-aarch64: warning: CPU-0 and CPU-4 in socket-0-cluster-0 \ have been associated with node-0 and node-1 respectively. \ It can cause OSes like Linux to misbehave : Skip the invalidation of CPU cluster and NUMA node boundary when qtest is enabled, to avoid the warning messages. Fixes: a494fdb715 ("numa: Validate cluster and NUMA node boundary if required") Signed-off-by: Gavin Shan <gshan@redhat.com> Reviewed-by: Peter Maydell <peter.maydell@linaro.org> Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
2024-01-05machine: Print CPU model name instead of CPU typeGavin Shan
The names of supported CPU models instead of CPU types should be printed when the user specified CPU type isn't supported, to be consistent with the output from '-cpu ?'. Correct the error messages to print CPU model names instead of CPU type names. Signed-off-by: Gavin Shan <gshan@redhat.com> Reviewed-by: Philippe Mathieu-Daudé <philmd@linaro.org> Message-ID: <20231204004726.483558-5-gshan@redhat.com> Signed-off-by: Philippe Mathieu-Daudé <philmd@linaro.org>
2024-01-05machine: Improve is_cpu_type_supported()Gavin Shan
It's no sense to check the CPU type when mc->valid_cpu_types[0] is NULL, which is a program error. Raise an assert on this. A precise hint for the error message is given when mc->valid_cpu_types[0] is the only valid entry. Besides, enumeration on mc->valid_cpu_types[0] when we have mutiple valid entries there is avoided to increase the code readability, as suggested by Philippe Mathieu-Daudé. Besides, @cc comes from machine->cpu_type or mc->default_cpu_type. For the later case, it can be NULL and it's also a program error. We should use assert() in this case. Signed-off-by: Gavin Shan <gshan@redhat.com> Message-ID: <20231204004726.483558-4-gshan@redhat.com> Signed-off-by: Philippe Mathieu-Daudé <philmd@linaro.org>
2024-01-05machine: Introduce helper is_cpu_type_supported()Gavin Shan
The logic, to check if the specified CPU type is supported in machine_run_board_init(), is independent enough. Factor it out into helper is_cpu_type_supported(). machine_run_board_init() looks a bit clean with this. Since we're here, @machine_class is renamed to @mc to avoid multiple line spanning of code. The comments are tweaked a bit either. No functional change intended. Signed-off-by: Gavin Shan <gshan@redhat.com> Reviewed-by: Philippe Mathieu-Daudé <philmd@linaro.org> Message-ID: <20231204004726.483558-3-gshan@redhat.com> [PMD: Only call new helper if machine->cpu_type is not NULL] Signed-off-by: Philippe Mathieu-Daudé <philmd@linaro.org>
2024-01-05machine: Use error handling when CPU type is checkedGavin Shan
Functions that use an Error **errp parameter to return errors should not also report them to the user, because reporting is the caller's job. The principle is violated by machine_run_board_init() because it calls error_report(), error_printf(), and exit(1) when the machine doesn't support the requested CPU type. Clean this up by using error_setg() and error_append_hint() instead. No functional change, as the only caller passes &error_fatal. Suggested-by: Igor Mammedov <imammedo@redhat.com> Signed-off-by: Gavin Shan <gshan@redhat.com> Reviewed-by: Markus Armbruster <armbru@redhat.com> Message-ID: <20231204004726.483558-2-gshan@redhat.com> [PMD: Correct error_append_hint() argument] Signed-off-by: Philippe Mathieu-Daudé <philmd@linaro.org>
2024-01-05hw/core: Add machine_class_default_cpu_type()Philippe Mathieu-Daudé
Add a helper to return a machine default CPU type. If this machine is restricted to a single CPU type, use it as default, obviously. Signed-off-by: Philippe Mathieu-Daudé <philmd@linaro.org> Reviewed-by: Richard Henderson <richard.henderson@linaro.org> Message-Id: <20231116163726.28952-1-philmd@linaro.org>
2023-12-20hw: Add compat machines for 9.0Cornelia Huck
Add 9.0 machine types for arm/i440fx/m68k/q35/s390x/spapr. Signed-off-by: Cornelia Huck <cohuck@redhat.com> Message-ID: <20231120094259.1191804-1-cohuck@redhat.com> Acked-by: Thomas Huth <thuth@redhat.com> Reviewed-by: Harsh Prateek Bora <harshpb@linux.ibm.com> Reviewed-by: Gavin Shan <gshan@redhat.com> Acked-by: Eric Farman <farman@linux.ibm.com> # s390x Signed-off-by: Thomas Huth <thuth@redhat.com>
2023-11-13igb: Add Function Level Reset to PF and VFCédric Le Goater
The Intel 82576EB GbE Controller say that the Physical and Virtual Functions support Function Level Reset. Add the capability to the PF device model using device property "x-pcie-flr-init" which is "on" by default and "off" for machines <= 8.1 to preserve compatibility. The FLR capability of the VF model is defined according to the FLR property of the PF, this to avoid adding an extra compatibility property. Cc: Sriram Yagnaraman <sriram.yagnaraman@est.tech> Fixes: 3a977deebe6b ("Intrdocue igb device emulation") Reviewed-by: Akihiko Odaki <akihiko.odaki@daynix.com> Tested-by: Akihiko Odaki <akihiko.odaki@daynix.com> Signed-off-by: Cédric Le Goater <clg@redhat.com> Signed-off-by: Jason Wang <jasowang@redhat.com>
2023-10-20CPU topology: extend with s390 specificsPierre Morel
S390 adds two new SMP levels, drawers and books to the CPU topology. S390 CPUs have specific topology features like dedication and entitlement. These indicate to the guest information on host vCPU scheduling and help the guest make better scheduling decisions. Add the new levels to the relevant QAPI structs. Add all the supported topology levels, dedication and entitlement as properties to S390 CPUs. Create machine-common.json so we can later include it in machine-target.json also. Signed-off-by: Pierre Morel <pmorel@linux.ibm.com> Reviewed-by: Nina Schoetterl-Glausch <nsg@linux.ibm.com> Co-developed-by: Nina Schoetterl-Glausch <nsg@linux.ibm.com> Reviewed-by: Thomas Huth <thuth@redhat.com> Signed-off-by: Nina Schoetterl-Glausch <nsg@linux.ibm.com> Message-ID: <20231016183925.2384704-3-nsg@linux.ibm.com> Signed-off-by: Thomas Huth <thuth@redhat.com>
2023-10-18hw/vfio: add ramfb migration supportMarc-André Lureau
Add a "VFIODisplay" subsection whenever "x-ramfb-migrate" is turned on. Turn it off by default on machines <= 8.1 for compatibility reasons. Signed-off-by: Marc-André Lureau <marcandre.lureau@redhat.com> Reviewed-by: Laszlo Ersek <lersek@redhat.com> Acked-by: Gerd Hoffmann <kraxel@redhat.com> [ clg: - checkpatch fixes - improved warn_report() in vfio_realize() ] Signed-off-by: Cédric Le Goater <clg@redhat.com>
2023-10-18ramfb-standalone: add migration supportMarc-André Lureau
Add a "ramfb-dev" section whenever "x-migrate" is turned on. Turn it off by default on machines <= 8.1 for compatibility reasons. Signed-off-by: Marc-André Lureau <marcandre.lureau@redhat.com> Reviewed-by: Laszlo Ersek <lersek@redhat.com> Acked-by: Gerd Hoffmann <kraxel@redhat.com> Signed-off-by: Cédric Le Goater <clg@redhat.com>
2023-10-05Merge tag 'for_upstream' of https://git.kernel.org/pub/scm/virt/kvm/mst/qemu ↵Stefan Hajnoczi
into staging virtio,pci: features, cleanups vdpa: shadow vq vlan support net migration with cvq cxl: support emulating 4 HDM decoders serial number extended capability virtio: hared dma-buf Fixes, cleanups all over the place. Signed-off-by: Michael S. Tsirkin <mst@redhat.com> * tag 'for_upstream' of https://git.kernel.org/pub/scm/virt/kvm/mst/qemu: (53 commits) libvhost-user: handle shared_object msg vhost-user: add shared_object msg hw/display: introduce virtio-dmabuf util/uuid: add a hash function virtio: remove unused next argument from virtqueue_split_read_next_desc() virtio: remove unnecessary thread fence while reading next descriptor virtio: use shadow_avail_idx while checking number of heads libvhost-user.c: add assertion to vu_message_read_default pcie_sriov: unregister_vfs(): fix error path hw/i386/pc: improve physical address space bound check for 32-bit x86 systems amd_iommu: Fix APIC address check vdpa net: follow VirtIO initialization properly at cvq isolation probing vdpa net: stop probing if cannot set features vdpa net: fix error message setting virtio status hw/pci-bridge/cxl-upstream: Add serial number extended capability support hw/cxl: Support 4 HDM decoders at all levels of topology hw/cxl: Fix and use same calculation for HDM decoder block size everywhere hw/cxl: Add utility functions decoder interleave ways and target count. hw/cxl: Push cxl_decoder_count_enc() and cxl_decode_ig() into .c vdpa net: zero vhost_vdpa iova_tree pointer at cleanup ... Conflicts: hw/core/machine.c Context conflict with commit 314e0a84cd5d ("hw/core: remove needless includes") because it removed an adjacent #include.
2023-10-04Merge tag 'misc-pull-request' of https://gitlab.com/marcandre.lureau/qemu ↵Stefan Hajnoczi
into staging Misc fixes and cleanups # -----BEGIN PGP SIGNATURE----- # # iQJQBAABCAA6FiEEh6m9kz+HxgbSdvYt2ujhCXWWnOUFAmUcClAcHG1hcmNhbmRy # ZS5sdXJlYXVAcmVkaGF0LmNvbQAKCRDa6OEJdZac5R5FD/9oeCDGXVzkm52K0DoW # 90N5Blda/3exvnS49TEz+rbIxXcy9IBxEKV3aPesCDw0V7Vxy6ZijPA/aHKzQEeP # DOX+0sELWLFRKvNNuXLxPlZcEQDgXkgqoCKf+0jp5oH7TAL2upezMhIr4XlUwG3v # rKQstpmr0Jm9sjsBTL9uIZCJpzglWk7CIbgAlBjOX6MFz0HAManrhBBuguvSZtrW # wYWrdkBEdTK6ranBvRA3IKi4ux/pmNsCpCtuOVT+WOLjC/wmJIE8+pBzlK9eOdqW # bPaxuu4XK1qao1+z6EyoaUtH/UW50EUInGq7aR2Z31/S1BLxqEpFCCnPAw7RGYZO # VlAuiR2U7K7AHFDfp8fJaUNH8a3Zh2wzpba5cyQ7LqVNRVbDhx65sQZw0pA3pjfi # JG0brIpWldD7auJtZTdCxXcoHWxeyfqqzH3a6GpeZzrRwuuAwxv0+yGF3Y2cMJ7+ # lV9JVcei5M+Acq1UfO4BCC77UpXs4Jl0+zyRq02vOJFnfwcLMQ7VjD2A3e00yodj # F5cPnbacI212ynNm925RNv45svaY1hD2Z8kJRV/15/04m9dRv4WHOOTuF3iwZjt1 # 9gp/p949tcEL/rBbDF+9QZiVHTWurVCQ0ZFnNhVnbKm+Hm5nHk5slc2p+VXQ0KB0 # E2mN1irWzLov0K1YZTfetiXo8A== # =3ol2 # -----END PGP SIGNATURE----- # gpg: Signature made Tue 03 Oct 2023 08:34:24 EDT # gpg: using RSA key 87A9BD933F87C606D276F62DDAE8E10975969CE5 # gpg: issuer "marcandre.lureau@redhat.com" # gpg: Good signature from "Marc-André Lureau <marcandre.lureau@redhat.com>" [full] # gpg: aka "Marc-André Lureau <marcandre.lureau@gmail.com>" [full] # Primary key fingerprint: 87A9 BD93 3F87 C606 D276 F62D DAE8 E109 7596 9CE5 * tag 'misc-pull-request' of https://gitlab.com/marcandre.lureau/qemu: chardev/char-pty: Avoid losing bytes when the other side just (re-)connected hw/display/ramfb: plug slight guest-triggerable leak on mode setting hw/pc: remove needless includes hw/core: remove needless includes analyze-migration: ignore RAM_SAVE_FLAG_MULTIFD_FLUSH ui/gtk: fix UI info precondition win32: avoid discarding the exception handler ui: add XBGR8888 and ABGR8888 in drm_format_pixman_map ui/console: sanitize search in qemu_graphic_console_is_multihead() ui/console: eliminate QOM properties from qemu_console_is_multihead() ui/console: only walk QemuGraphicConsoles in qemu_console_is_multihead() ui/console: make qemu_console_is_multihead() static input: Allow to choose console with qemu_input_is_absolute Signed-off-by: Stefan Hajnoczi <stefanha@redhat.com>
2023-10-04pci: SLT must be ROMichael S. Tsirkin
current code sets PCI_SEC_LATENCY_TIMER to RW, but for pcie to pcie bridges it must be RO 0 according to pci express spec which says: This register does not apply to PCI Express. It must be read-only and hardwired to 00h. For PCI Express to PCI/PCI-X Bridges, refer to the [PCIe-to-PCI-PCI-X-Bridge] for requirements for this register. also, fix typo in comment where it's made writeable - this typo is likely what prevented us noticing we violate this requirement in the 1st place. Reported-by: Marcin Juszkiewicz <marcin.juszkiewicz@linaro.org> Message-Id: <de9d05366a70172e1789d10591dbe59e39c3849c.1693432039.git.mst@redhat.com> Tested-by: Marcin Juszkiewicz <marcin.juszkiewicz@linaro.org> Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
2023-10-03Merge tag 'for-upstream' of https://gitlab.com/bonzini/qemu into stagingStefan Hajnoczi
* fix from optionrom build * fix for KVM on Apple M2 * introduce machine property "audiodev" * ui/vnc: Require audiodev= to enable audio * audio: remove QEMU_AUDIO_* and -audio-help support * audio: forbid using default audiodev backend with -audiodev and -nodefaults * remove compatibility code for old machine types * make-release: do not ship dtc sources * build system cleanups # -----BEGIN PGP SIGNATURE----- # # iQFIBAABCAAyFiEE8TM4V0tmI4mGbHaCv/vSX3jHroMFAmUb0QgUHHBib256aW5p # QHJlZGhhdC5jb20ACgkQv/vSX3jHroOpnAf9EFXfGkXpqQ5Q8ZbVlVc5GQKofMHW # OZwamTBlp/c07+QcQiMxwLhIW0iyDhrfdCjoFSUaTA8O10FM1YrFv4SkUryYb9B3 # bmoTl4NeLvmkxpC47GEeaaBfjyM0G/9Ip9Zsuqx3u+gSzwTbkEstA2u7gcsN0tL9 # VlhMSiV82uHhRC/DJYLxr+8bRYSIm1AeuI8K/O1yags85Kztf3UiQUhePIKLznMH # BdORjD+i46xM1dE8ifpdsunm462cDWz/faAnIH0YVKBlshnQHXKTO+GDA/Fbfl51 # wFfupZXo93wwgawS7elAUzI+gwaKCPRHA8NDcukeO91hTzk6i14y04u5SQ== # =nv64 # -----END PGP SIGNATURE----- # gpg: Signature made Tue 03 Oct 2023 04:30:00 EDT # gpg: using RSA key F13338574B662389866C7682BFFBD25F78C7AE83 # gpg: issuer "pbonzini@redhat.com" # gpg: Good signature from "Paolo Bonzini <bonzini@gnu.org>" [full] # gpg: aka "Paolo Bonzini <pbonzini@redhat.com>" [full] # Primary key fingerprint: 46F5 9FBD 57D6 12E7 BFD4 E2F7 7E15 100C CD36 69B1 # Subkey fingerprint: F133 3857 4B66 2389 866C 7682 BFFB D25F 78C7 AE83 * tag 'for-upstream' of https://gitlab.com/bonzini/qemu: (24 commits) audio: forbid default audiodev backend with -nodefaults audio: propagate Error * out of audio_init vt82c686 machines: Support machine-default audiodev with fallback hw/ppc: Support machine-default audiodev with fallback hw/arm: Support machine-default audiodev with fallback Introduce machine property "audiodev" audio: remove QEMU_AUDIO_* and -audio-help support audio: simplify flow in audio_init audio: commonize voice initialization audio: return Error ** from audio_state_by_name audio: allow returning an error from the driver init audio: Require AudioState in AUD_add_capture ui/vnc: Require audiodev= to enable audio crypto: only include tls-cipher-suites in emulators scsi-disk: ensure that FORMAT UNIT commands are terminated esp: restrict non-DMA transfer length to that of available data esp: use correct type for esp_dma_enable() in sysbus_esp_gpio_demux() Makefile: build plugins before running TCG tests meson: clean up static_library keyword arguments make-release: do not ship dtc sources ... Signed-off-by: Stefan Hajnoczi <stefanha@redhat.com>
2023-10-03hw/core: remove needless includesMarc-André Lureau
The include list is large, make it smaller. Signed-off-by: Marc-André Lureau <marcandre.lureau@redhat.com> Acked-by: Laszlo Ersek <lersek@redhat.com>
2023-10-03Introduce machine property "audiodev"Martin Kletzander
Many machine types have default audio devices with no way to set the underlying audiodev. Instead of adding an option for each and every one of them, this new property can be used as a default during machine initialisation when creating such devices. Signed-off-by: Martin Kletzander <mkletzan@redhat.com> [Make the property optional, instead of including it in all machines. - Paolo] Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2023-09-29hw/core/machine: Clean up local variable shadowingPhilippe Mathieu-Daudé
Fix: hw/core/machine.c: In function ‘machine_initfn’: hw/core/machine.c:1081:17: warning: declaration of ‘obj’ shadows a parameter [-Wshadow=compatible-local] 1081 | Object *obj = OBJECT(ms); | ^~~ hw/core/machine.c:1065:36: note: shadowed declaration is here 1065 | static void machine_initfn(Object *obj) | ~~~~~~~~^~~ Signed-off-by: Philippe Mathieu-Daudé <philmd@linaro.org> Message-ID: <20230904162824.85385-2-philmd@linaro.org> Reviewed-by: Peter Maydell <peter.maydell@linaro.org> Signed-off-by: Markus Armbruster <armbru@redhat.com>
2023-09-21hw/other: spelling fixesMichael Tokarev
Signed-off-by: Michael Tokarev <mjt@tls.msk.ru> Reviewed-by: Peter Maydell <peter.maydell@linaro.org>
2023-09-19Merge tag 'mem-2023-09-19' of https://github.com/davidhildenbrand/qemu into ↵Stefan Hajnoczi
staging Hi, "Host Memory Backends" and "Memory devices" queue ("mem"): - Support and document VM templating with R/O files using a new "rom" parameter for memory-backend-file - Some cleanups and fixes around NVDIMMs and R/O file handling for guest RAM - Optimize ioeventfd updates by skipping address spaces that are not applicable # -----BEGIN PGP SIGNATURE----- # # iQJFBAABCAAvFiEEG9nKrXNcTDpGDfzKTd4Q9wD/g1oFAmUJdykRHGRhdmlkQHJl # ZGhhdC5jb20ACgkQTd4Q9wD/g1pf2w//akOUoYMuamySGjXtKLVyMKZkjIys+Ama # k2C0xzsWAHBP572ezwHi8uxf5j9kzAjsw6GxDZ7FAamD9MhiohkEvkecloBx6f/c # q3fVHblBNkG7v2urtf4+6PJtJvhzOST2SFXfWeYhO/vaA04AYCDgexv82JN3gA6B # OS8WyOX62b8wILPSY2GLZ8IqpE9XnOYZwzVBn6YB1yo7ZkYEfXO6cA8nykNuNcOE # vppqDo7uVIX6317FWj8ygxmzFfOaj0WT2MT2XFzEIDfg8BInQN8HC4mTn0hcVKMa # N1y+eZH733CQKT+uNBRZ5YOeljOi4d6gEEyvkkA/L7e5D3Qg9hIdvHb4uryCFSWX # Vt07OP1XLBwCZFobOC6sg+2gtTZJxxYK89e6ZzEd0454S24w5bnEteRAaCGOP0XL # ww9xYULqhtZs55UC4rvZHJwdUAk1fIY4VqynwkeQXegvz6BxedNeEkJiiEU0Tizx # N2VpsxAJ7H/LLSFeZoCRESo4azrH6U4n7S/eS1tkCniFqibfe2yIQCDoJVfb42ec # gfg/vThCrDwHkIHzkMmoV8NndA7Q7SIkyMfYeEEBeZMeg8JzYll4DJEw/jQCacxh # KRUa+AZvGlTJUq0mkvyOVfLki+iaehoIUuY1yvMrmdWijPO8n3YybmP9Ljhr8VdR # 9MSYZe+I2v8= # =iraT # -----END PGP SIGNATURE----- # gpg: Signature made Tue 19 Sep 2023 06:25:45 EDT # gpg: using RSA key 1BD9CAAD735C4C3A460DFCCA4DDE10F700FF835A # gpg: issuer "david@redhat.com" # gpg: Good signature from "David Hildenbrand <david@redhat.com>" [unknown] # gpg: aka "David Hildenbrand <davidhildenbrand@gmail.com>" [full] # gpg: aka "David Hildenbrand <hildenbr@in.tum.de>" [unknown] # gpg: WARNING: The key's User ID is not certified with a trusted signature! # gpg: There is no indication that the signature belongs to the owner. # Primary key fingerprint: 1BD9 CAAD 735C 4C3A 460D FCCA 4DDE 10F7 00FF 835A * tag 'mem-2023-09-19' of https://github.com/davidhildenbrand/qemu: memory: avoid updating ioeventfds for some address_space machine: Improve error message when using default RAM backend id softmmu/physmem: Hint that "readonly=on,rom=off" exists when opening file R/W for private mapping fails docs: Start documenting VM templating docs: Don't mention "-mem-path" in multi-process.rst softmmu/physmem: Never return directories from file_ram_open() softmmu/physmem: Fail creation of new files in file_ram_open() with readonly=true softmmu/physmem: Bail out early in ram_block_discard_range() with readonly files softmmu/physmem: Remap with proper protection in qemu_ram_remap() backends/hostmem-file: Add "rom" property to support VM templating with R/O files softmmu/physmem: Distinguish between file access mode and mmap protection nvdimm: Reject writing label data to ROM instead of crashing QEMU Signed-off-by: Stefan Hajnoczi <stefanha@redhat.com>
2023-09-19machine: Improve error message when using default RAM backend idDavid Hildenbrand
For migration purposes, users might want to reuse the default RAM backend id, but specify a different memory backend. For example, to reuse "pc.ram" on q35, one has to set -machine q35,memory-backend=pc.ram Only then, can a memory backend with the id "pc.ram" be created manually. Let's improve the error message by improving the hint. Use error_append_hint() -- which in turn requires ERRP_GUARD(). Message-ID: <20230906120503.359863-12-david@redhat.com> Suggested-by: ThinerLogoer <logoerthiner1@163.com> Reviewed-by: Philippe Mathieu-Daudé <philmd@linaro.org> Tested-by: Mario Casquero <mcasquer@redhat.com> Reviewed-by: Markus Armbruster <armbru@redhat.com> Signed-off-by: David Hildenbrand <david@redhat.com>
2023-09-18virtio-net: Add support for USO featuresYuri Benditovich
USO features of virtio-net device depend on kernel ability to support them, for backward compatibility by default the features are disabled on 8.0 and earlier. Signed-off-by: Yuri Benditovich <yuri.benditovich@daynix.com> Signed-off-by: Andrew Melnychecnko <andrew@daynix.com> Signed-off-by: Jason Wang <jasowang@redhat.com>
2023-08-23hw: Add compat machines for 8.2Cornelia Huck
Add 8.2 machine types for arm/i440fx/m68k/q35/s390x/spapr. Signed-off-by: Cornelia Huck <cohuck@redhat.com> Message-Id: <20230718142235.135319-1-cohuck@redhat.com> Reviewed-by: Thomas Huth <thuth@redhat.com> Reviewed-by: Cédric Le Goater <clg@kaod.org> Acked-by: Laurent Vivier <laurent@vivier.eu> Acked-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Thomas Huth <thuth@redhat.com>
2023-07-10pcie: Specify 0 for ARI next function numbersAkihiko Odaki
The current implementers of ARI are all SR-IOV devices. The ARI next function number field is undefined for VF according to PCI Express Base Specification Revision 5.0 Version 1.0 section 9.3.7.7. The PF still requires some defined value so end the linked list formed with the field by specifying 0 as required for any ARI implementation according to section 7.8.7.2. For migration, the field will keep having 1 as its value on the old QEMU machine versions. Fixes: 2503461691 ("pcie: Add some SR/IOV API documentation in docs/pcie_sriov.txt") Fixes: 44c2c09488 ("hw/nvme: Add support for SR-IOV") Fixes: 3a977deebe ("Intrdocue igb device emulation") Signed-off-by: Akihiko Odaki <akihiko.odaki@daynix.com> Reviewed-by: Ani Sinha <anisinha@redhat.com> Message-Id: <20230710153838.33917-3-akihiko.odaki@daynix.com> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
2023-06-26numa: Validate cluster and NUMA node boundary if requiredGavin Shan
For some architectures like ARM64, multiple CPUs in one cluster can be associated with different NUMA nodes, which is irregular configuration because we shouldn't have this in baremetal environment. The irregular configuration causes Linux guest to misbehave, as the following warning messages indicate. -smp 6,maxcpus=6,sockets=2,clusters=1,cores=3,threads=1 \ -numa node,nodeid=0,cpus=0-1,memdev=ram0 \ -numa node,nodeid=1,cpus=2-3,memdev=ram1 \ -numa node,nodeid=2,cpus=4-5,memdev=ram2 \ ------------[ cut here ]------------ WARNING: CPU: 0 PID: 1 at kernel/sched/topology.c:2271 build_sched_domains+0x284/0x910 Modules linked in: CPU: 0 PID: 1 Comm: swapper/0 Not tainted 5.14.0-268.el9.aarch64 #1 pstate: 00400005 (nzcv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--) pc : build_sched_domains+0x284/0x910 lr : build_sched_domains+0x184/0x910 sp : ffff80000804bd50 x29: ffff80000804bd50 x28: 0000000000000002 x27: 0000000000000000 x26: ffff800009cf9a80 x25: 0000000000000000 x24: ffff800009cbf840 x23: ffff000080325000 x22: ffff0000005df800 x21: ffff80000a4ce508 x20: 0000000000000000 x19: ffff000080324440 x18: 0000000000000014 x17: 00000000388925c0 x16: 000000005386a066 x15: 000000009c10cc2e x14: 00000000000001c0 x13: 0000000000000001 x12: ffff00007fffb1a0 x11: ffff00007fffb180 x10: ffff80000a4ce508 x9 : 0000000000000041 x8 : ffff80000a4ce500 x7 : ffff80000a4cf920 x6 : 0000000000000001 x5 : 0000000000000001 x4 : 0000000000000007 x3 : 0000000000000002 x2 : 0000000000001000 x1 : ffff80000a4cf928 x0 : 0000000000000001 Call trace: build_sched_domains+0x284/0x910 sched_init_domains+0xac/0xe0 sched_init_smp+0x48/0xc8 kernel_init_freeable+0x140/0x1ac kernel_init+0x28/0x140 ret_from_fork+0x10/0x20 Improve the situation to warn when multiple CPUs in one cluster have been associated with different NUMA nodes. However, one NUMA node is allowed to be associated with different clusters. Signed-off-by: Gavin Shan <gshan@redhat.com> Acked-by: Philippe Mathieu-Daudé <philmd@linaro.org> Acked-by: Igor Mammedov <imammedo@redhat.com> Message-Id: <20230509002739.18388-2-gshan@redhat.com> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2023-05-26machine: do not crash if default RAM backend name has been stolenIgor Mammedov
QEMU aborts when default RAM backend should be used (i.e. no explicit '-machine memory-backend=' specified) but user has created an object which 'id' equals to default RAM backend name used by board. $QEMU -machine pc \ -object memory-backend-ram,id=pc.ram,size=4294967296 Actual results: QEMU 7.2.0 monitor - type 'help' for more information (qemu) Unexpected error in object_property_try_add() at ../qom/object.c:1239: qemu-kvm: attempt to add duplicate property 'pc.ram' to object (type 'container') Aborted (core dumped) Instead of abort, check for the conflicting 'id' and exit with an error, suggesting how to remedy the issue. Buglink: https://bugzilla.redhat.com/show_bug.cgi?id=2207886 Signed-off-by: Igor Mammedov <imammedo@redhat.com> Message-Id: <20230522131717.3780533-1-imammedo@redhat.com> Tested-by: Thomas Huth <thuth@redhat.com> Reviewed-by: Thomas Huth <thuth@redhat.com> Reviewed-by: Shaoqin Huang <shahuang@redhat.com> Reviewed-by: Philippe Mathieu-Daudé <philmd@linaro.org> Signed-off-by: Thomas Huth <thuth@redhat.com>
2023-05-19hw/pci: Disable PCI_ERR_UNCOR_MASK register for machine type < 8.0Leonardo Bras
Since it's implementation on v8.0.0-rc0, having the PCI_ERR_UNCOR_MASK set for machine types < 8.0 will cause migration to fail if the target QEMU version is < 8.0.0 : qemu-system-x86_64: get_pci_config_device: Bad config data: i=0x10a read: 40 device: 0 cmask: ff wmask: 0 w1cmask:0 qemu-system-x86_64: Failed to load PCIDevice:config qemu-system-x86_64: Failed to load e1000e:parent_obj qemu-system-x86_64: error while loading state for instance 0x0 of device '0000:00:02.0/e1000e' qemu-system-x86_64: load of migration failed: Invalid argument The above test migrated a 7.2 machine type from QEMU master to QEMU 7.2.0, with this cmdline: ./qemu-system-x86_64 -M pc-q35-7.2 [-incoming XXX] In order to fix this, property x-pcie-err-unc-mask was introduced to control when PCI_ERR_UNCOR_MASK is enabled. This property is enabled by default, but is disabled if machine type <= 7.2. Fixes: 010746ae1d ("hw/pci/aer: Implement PCI_ERR_UNCOR_MASK register") Suggested-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Leonardo Bras <leobras@redhat.com> Message-Id: <20230503002701.854329-1-leobras@redhat.com> Reviewed-by: Jonathan Cameron <Jonathan.Cameron@huawei.com> Reviewed-by: Peter Xu <peterx@redhat.com> Reviewed-by: Juan Quintela <quintela@redhat.com> Fixes: https://gitlab.com/qemu-project/qemu/-/issues/1576 Tested-by: Fiona Ebner <f.ebner@proxmox.com> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
2023-04-27multifd: Create property multifd-flush-after-each-sectionJuan Quintela
We used to flush all channels at the end of each RAM section sent. That is not needed, so preparing to only flush after a full iteration through all the RAM. Default value of the property is false. But we return "true" in migrate_multifd_flush_after_each_section() until we implement the code in following patches. Signed-off-by: Juan Quintela <quintela@redhat.com> Reviewed-by: Dr. David Alan Gilbert <dgilbert@redhat.com> Acked-by: Peter Xu <peterx@redhat.com> --- Rename each-iteration to after-each-section Rename multifd-sync-after-each-section to multifd-flush-after-each-section Move to machine-8.0 (peter)
2023-04-20hw: Add compat machines for 8.1Cornelia Huck
Add 8.1 machine types for arm/i440fx/m68k/q35/s390x/spapr. Signed-off-by: Cornelia Huck <cohuck@redhat.com> Message-Id: <20230314173009.152667-1-cohuck@redhat.com> Reviewed-by: Cédric Le Goater <clg@kaod.org> Reviewed-by: Thomas Huth <thuth@redhat.com> Acked-by: Gavin Shan <gshan@redhat.com> Signed-off-by: Thomas Huth <thuth@redhat.com>
2023-04-12migration: Fix potential race on postcopy_qemufile_srcPeter Xu
postcopy_qemufile_src object should be owned by one thread, either the main thread (e.g. when at the beginning, or at the end of migration), or by the return path thread (when during a preempt enabled postcopy migration). If that's not the case the access to the object might be racy. postcopy_preempt_shutdown_file() can be potentially racy, because it's called at the end phase of migration on the main thread, however during which the return path thread hasn't yet been recycled; the recycle happens in await_return_path_close_on_source() which is after this point. It means, logically it's posslbe the main thread and the return path thread are both operating on the same qemufile. While I don't think qemufile is thread safe at all. postcopy_preempt_shutdown_file() used to be needed because that's where we send EOS to dest so that dest can safely shutdown the preempt thread. To avoid the possible race, remove this only place that a race can happen. Instead we figure out another way to safely close the preempt thread on dest. The core idea during postcopy on deciding "when to stop" is that dest will send a postcopy SHUT message to src, telling src that all data is there. Hence to shut the dest preempt thread maybe better to do it directly on dest node. This patch proposed such a way that we change postcopy_prio_thread_created into PreemptThreadStatus, so that we kick the preempt thread on dest qemu by a sequence of: mis->preempt_thread_status = PREEMPT_THREAD_QUIT; qemu_file_shutdown(mis->postcopy_qemufile_dst); While here shutdown() is probably so far the easiest way to kick preempt thread from a blocked qemu_get_be64(). Then it reads preempt_thread_status to make sure it's not a network failure but a willingness to quit the thread. We could have avoided that extra status but just rely on migration status. The problem is postcopy_ram_incoming_cleanup() is just called early enough so we're still during POSTCOPY_ACTIVE no matter what.. So just make it simple to have the status introduced. One flag x-preempt-pre-7-2 is added to keep old pre-7.2 behaviors of postcopy preempt. Fixes: 9358982744 ("migration: Send requested page directly in rp-return thread") Signed-off-by: Peter Xu <peterx@redhat.com> Reviewed-by: Juan Quintela <quintela@redhat.com> Signed-off-by: Juan Quintela <quintela@redhat.com>
generated by cgit v1.2.3 (git 2.26.2) at 2025-03-23 05:08:46 +0000