summary refs log tree commit diff stats
path: root/scripts/shaderinclude.py (unfollow)
Commit message (Collapse)AuthorFilesLines
2025-10-07tests/lcitool: drop 64 bit guests from i686 cross buildAlex Bennée2-3/+1
With only TCG available we can't support 64 bit guests on a 32 bit host. Fixes: 5c27baf9519 (docs/about/deprecated: Deprecate 32-bit x86 hosts for system emulation) Reviewed-by: Marc-André Lureau <marcandre.lureau@redhat.com> Reviewed-by: Richard Henderson <richard.henderson@linaro.org> Signed-off-by: Alex Bennée <alex.bennee@linaro.org> Message-ID: <20251001170947.2769296-5-alex.bennee@linaro.org>
2025-10-07.gitmodules: restore qemu-project mirror of u-boot-sam460exAlex Bennée1-1/+2
With this change also reference the upstream repo. Signed-off-by: Alex Bennée <alex.bennee@linaro.org> Message-ID: <20251001170947.2769296-4-alex.bennee@linaro.org>
2025-10-07.gitmodules: restore qemu-project mirror of u-bootAlex Bennée1-1/+2
With this change also reference the upstream repo. Signed-off-by: Alex Bennée <alex.bennee@linaro.org> Message-ID: <20251001170947.2769296-3-alex.bennee@linaro.org>
2025-10-07.gitpublish: use origin/master as default baseAlex Bennée1-8/+8
This is very much the result of my recent fat finger but I think it's safer to assume that origin/master points to a recent commit (or at least a commit a given branch is based on) than master. Acked-by: Stefan Hajnoczi <stefanha@redhat.com> Signed-off-by: Alex Bennée <alex.bennee@linaro.org> Message-ID: <20251001170947.2769296-2-alex.bennee@linaro.org>
2025-10-06hw/intc/loongarch_dintc: Set class_size for LoongArchDINTCClassRichard Henderson1-0/+1
Fixes: 4d4baab24179 ("loongarch: add a direct interrupt controller device") Signed-off-by: Richard Henderson <richard.henderson@linaro.org>
2025-10-06scripts/checkpatch: Avoid recommending legacy qemu_bh_new_guarded()Philippe Mathieu-Daudé1-3/+3
qemu_bh_new_guarded() is considered legacy since commit 9c86c97f12c ("async: Add an optional reentrancy guard to the BH API"); recommend the new API: aio_bh_new_guarded(). Signed-off-by: Philippe Mathieu-Daudé <philmd@linaro.org> Message-ID: <20250924163911.51479-1-philmd@linaro.org> Signed-off-by: Stefan Hajnoczi <stefanha@redhat.com>
2025-10-05virtio: improve virtqueue mapping error messagesAlessandro Ratti3-3/+42
Improve error reporting when virtqueue ring mapping fails by including a device identifier in the error message. Introduce a helper qdev_get_printable_name() in qdev-core, which returns either: - the device ID, if explicitly provided (e.g. -device ...,id=foo) - the QOM path from qdev_get_dev_path(dev) otherwise - "<unknown device>" as a fallback when no identifier is present This makes it easier to identify which device triggered the error in multi-device setups or when debugging complex guest configurations. Resolves: https://gitlab.com/qemu-project/qemu/-/issues/230 Buglink: https://bugs.launchpad.net/qemu/+bug/1919021 Suggested-by: Markus Armbruster <armbru@redhat.com> Signed-off-by: Alessandro Ratti <alessandro@0x65c.net> Message-Id: <20250924093138.559872-2-alessandro@0x65c.net> Reviewed-by: Daniel P. Berrangé <berrange@redhat.com> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
2025-10-05pci: Fix wrong parameter passing to pci_device_get_iommu_bus_devfn()Zhenzhong Duan1-10/+8
The 2nd parameter of pci_device_get_iommu_bus_devfn() about root PCIBus backed by an IOMMU for the PCI device, the 3rd is about aliased PCIBus of the PCI device. Meanwhile the 3rd and 4th parameters are optional, pass NULL if they are not needed. Reviewed-by: Clément Mathieu--Drif <clement.mathieu--drif@eviden.com> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Message-ID: <20250929034206.439266-4-zhenzhong.duan@intel.com> Fixes: a849ff5d6f ("pci: Add a pci-level initialization function for IOMMU notifiers") Fixes: f0f37daf8e ("pci: Add a PCI-level API for PRI") Fixes: e9b457500a ("pci: Add a pci-level API for ATS") Fixes: 042cbc9aec ("pci: Add an API to get IOMMU's min page size and virtual address width") Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
2025-10-05intel_iommu: Simplify caching mode check with VFIO deviceZhenzhong Duan2-54/+6
In early days, we had different tricks to ensure caching-mode=on with VFIO device: 28cf553afe ("intel_iommu: Sanity check vfio-pci config on machine init done") c6cbc29d36 ("pc/q35: Disallow vfio-pci hotplug without VT-d caching mode") There is also a patch with the same purpose but for VDPA device: b8d78277c0 ("intel-iommu: fail MAP notifier without caching mode") Because without caching mode, MAP notifier won't work correctly since guest won't send IOTLB update event when it establishes new mappings in the I/O page tables. Now with host IOMMU device interface between VFIO and vIOMMU, we can simplify first two commits above with a small check in set_iommu_device(). This also works for future IOMMUFD backed VDPA implementation which may also need caching mode on. But for legacy VDPA we still need commit b8d78277c0 as it doesn't use the host IOMMU device interface. For coldplug VFIO device: qemu-system-x86_64: -device vfio-pci,host=0000:3b:00.0,id=hostdev3,bus=root0,iommufd=iommufd0: vfio 0000:3b:00.0: Failed to set vIOMMU: Device assignment is not allowed without enabling caching-mode=on for Intel IOMMU. For hotplug VFIO device: if "iommu=off" is configured in guest, Error: vfio 0000:3b:00.0: Failed to set vIOMMU: Device assignment is not allowed without enabling caching-mode=on for Intel IOMMU. else Error: vfio 0000:3b:00.0: memory listener initialization failed: Region vtd-00.0-dmar: device 01.00.0 requires caching mode: Operation not supported The specialty for hotplug is due to the check in commit b8d78277c0 happen before the check in set_iommu_device. Signed-off-by: Zhenzhong Duan <zhenzhong.duan@intel.com> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Message-ID: <20250929034206.439266-3-zhenzhong.duan@intel.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
2025-10-05intel_iommu: Enable Enhanced Set Root Table Pointer Support (ESRTPS)Zhenzhong Duan2-1/+2
According to VTD spec rev 4.1 section 6.6: "For implementations reporting the Enhanced Set Root Table Pointer Support (ESRTPS) field as Clear, on a 'Set Root Table Pointer' operation, software must perform a global invalidate of the context cache, PASID-cache (if applicable), and IOTLB, in that order. This is required to ensure hardware references only the remapping structures referenced by the new root table pointer and not stale cached entries. For implementations reporting the Enhanced Set Root Table Pointer Support (ESRTPS) field as Set, as part of 'Set Root Table Pointer' operation, hardware performs global invalidation on all DMA remapping translation caches and hence software is not required to perform additional invalidations" We already implemented ESRTPS capability in vtd_handle_gcmd_srtp() by calling vtd_reset_caches(), just set ESRTPS in DMAR_CAP_REG to avoid unnecessary global invalidation requests of context, PASID-cache and IOTLB from guest. This change doesn't impact migration as the content of DMAR_CAP_REG is migrated too. Signed-off-by: Zhenzhong Duan <zhenzhong.duan@intel.com> Reviewed-by: Clément Mathieu--Drif <clement.mathieu--drif@eviden.com> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Message-ID: <20250929034206.439266-2-zhenzhong.duan@intel.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
2025-10-05vdpa-dev: add get_vhost() callback for vhost-vdpa deviceLi Zhaoxin1-0/+7
Commit c255488d67 "virtio: add vhost support for virtio devices" added the get_vhost() function, but it did not include vhost-vdpa devices. So when I use the vdpa device and query the status of the vdpa device with the x-query-virtio-status qmp command, since vdpa does not implement vhost_get, it will cause qemu to crash. Therefore, in order to obtain the status of the virtio device under vhost-vdpa, we need to add a vhost_get implement for the vdpa device. Co-developed-by: Miao Kezhan <miaokezhan@baidu.com> Signed-off-by: Miao Kezhan <miaokezhan@baidu.com> Signed-off-by: Li Zhaoxin <lizhaoxin04@baidu.com> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Message-ID: <2778f817cb6740a15ecb37927804a67288b062d1.1758860411.git.lizhaoxin04@baidu.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
2025-10-05amd_iommu: HATDis/HATS=11 supportJoao Martins3-1/+25
Add a way to disable DMA translation support in AMD IOMMU by allowing to set IVHD HATDis to 1, and exposing HATS (Host Address Translation Size) as Reserved value. Signed-off-by: Joao Martins <joao.m.martins@oracle.com> Signed-off-by: Alejandro Jimenez <alejandro.j.jimenez@oracle.com> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Message-ID: <20250919213515.917111-23-alejandro.j.jimenez@oracle.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
2025-10-05intel-iommu: Move dma_translation to x86-iommuJoao Martins3-3/+4
To be later reused by AMD, now that it shares similar property. Signed-off-by: Joao Martins <joao.m.martins@oracle.com> Signed-off-by: Alejandro Jimenez <alejandro.j.jimenez@oracle.com> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Message-ID: <20250919213515.917111-22-alejandro.j.jimenez@oracle.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
2025-10-05amd_iommu: Refactor amdvi_page_walk() to use common code for page walkAlejandro Jimenez1-50/+27
Simplify amdvi_page_walk() by making it call the fetch_pte() helper that is already in use by the shadow page synchronization code. Ensures all code uses the same page table walking algorithm. Signed-off-by: Alejandro Jimenez <alejandro.j.jimenez@oracle.com> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Message-ID: <20250919213515.917111-21-alejandro.j.jimenez@oracle.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
2025-10-05amd_iommu: Do not assume passthrough translation when DTE[TV]=0Alejandro Jimenez1-39/+48
The AMD I/O Virtualization Technology (IOMMU) Specification (see Table 8: V, TV, and GV Fields in Device Table Entry), specifies that a DTE with V=1, TV=0 does not contain a valid address translation information. If a request requires a table walk, the walk is terminated when this condition is encountered. Do not assume that addresses for a device with DTE[TV]=0 are passed through (i.e. not remapped) and instead terminate the page table walk early. Fixes: d29a09ca6842 ("hw/i386: Introduce AMD IOMMU") Signed-off-by: Alejandro Jimenez <alejandro.j.jimenez@oracle.com> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Message-ID: <20250919213515.917111-20-alejandro.j.jimenez@oracle.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
2025-10-05amd_iommu: Toggle address translation mode on devtab entry invalidationAlejandro Jimenez1-2/+120
A guest must issue an INVALIDATE_DEVTAB_ENTRY command after changing a Device Table entry (DTE) e.g. after attaching a device and setting up its DTE. When intercepting this event, determine if the DTE has been configured for paging or not, and toggle the appropriate memory regions to allow DMA address translation for the address space if needed. Requires dma-remap=on. Signed-off-by: Alejandro Jimenez <alejandro.j.jimenez@oracle.com> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Message-ID: <20250919213515.917111-19-alejandro.j.jimenez@oracle.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
2025-10-05amd_iommu: Add dma-remap property to AMD vIOMMU deviceAlejandro Jimenez2-7/+20
In order to enable device assignment with IOMMU protection and guest DMA address translation, IOMMU MAP notifier support is necessary to allow users like VFIO to synchronize the shadow page tables i.e. to receive notifications when the guest updates its I/O page tables and replay the mappings onto host I/O page tables. Provide a new dma-remap property to govern the ability to register for MAP notifications, effectively providing global control over the DMA address translation functionality that was implemented in previous changes. Note that DMA remapping support also requires the vIOMMU is configured with the NpCache capability, so a guest driver issues IOMMU invalidations for both map() and unmap() operations. This capability is already set by default and written to the configuration in amdvi_pci_realize() as part of AMDVI_CAPAB_FEATURES. Signed-off-by: Alejandro Jimenez <alejandro.j.jimenez@oracle.com> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Message-ID: <20250919213515.917111-18-alejandro.j.jimenez@oracle.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
2025-10-05amd_iommu: Set all address spaces to use passthrough mode on resetAlejandro Jimenez1-0/+30
On reset, restore the default address translation mode (passthrough) for all the address spaces managed by the vIOMMU. Signed-off-by: Alejandro Jimenez <alejandro.j.jimenez@oracle.com> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Message-ID: <20250919213515.917111-17-alejandro.j.jimenez@oracle.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
2025-10-05amd_iommu: Toggle memory regions based on address translation modeAlejandro Jimenez1-2/+21
Enable the appropriate memory region for an address space depending on the address translation mode selected for it. This is currently based on a generic x86 IOMMU property, and only done during the address space initialization. Extract the code into a helper and toggle the regions based on whether the specific address space is using address translation (via the newly introduced addr_translation field). Later, region activation will also be controlled by availability of DMA remapping capability (via dma-remap property to be introduced in follow up changes). Signed-off-by: Alejandro Jimenez <alejandro.j.jimenez@oracle.com> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Message-ID: <20250919213515.917111-16-alejandro.j.jimenez@oracle.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
2025-10-05amd_iommu: Invalidate address translations on INVALIDATE_IOMMU_ALLAlejandro Jimenez1-0/+48
When the kernel IOMMU driver issues an INVALIDATE_IOMMU_ALL, the address translation and interrupt remapping information must be cleared for all Device IDs and all domains. Introduce a helper to sync the shadow page table for all the address spaces with registered notifiers, which replays both MAP and UNMAP events. Signed-off-by: Alejandro Jimenez <alejandro.j.jimenez@oracle.com> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Message-ID: <20250919213515.917111-15-alejandro.j.jimenez@oracle.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
2025-10-05amd_iommu: Add replay callbackAlejandro Jimenez1-0/+24
A replay() method is necessary to efficiently synchronize the host page tables after VFIO registers a notifier for IOMMU events. It is called to ensure that existing mappings from an IOMMU memory region are "replayed" to a specified notifier, initializing or updating the shadow page tables on the host. Signed-off-by: Alejandro Jimenez <alejandro.j.jimenez@oracle.com> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Message-ID: <20250919213515.917111-14-alejandro.j.jimenez@oracle.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
2025-10-05amd_iommu: Unmap all address spaces under the AMD IOMMU on resetAlejandro Jimenez1-0/+74
Support dropping all existing mappings on reset. When the guest kernel reboots it will create new ones, but other components that run before the kernel (e.g. OVMF) should not be able to use existing mappings from the previous boot. Signed-off-by: Alejandro Jimenez <alejandro.j.jimenez@oracle.com> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Message-ID: <20250919213515.917111-13-alejandro.j.jimenez@oracle.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
2025-10-05amd_iommu: Use iova_tree records to determine large page size on UNMAPAlejandro Jimenez1-6/+89
Keep a record of mapped IOVA ranges per address space, using the iova_tree implementation. Besides enabling optimizations like avoiding unnecessary notifications, a record of existing <IOVA, size> mappings makes it possible to determine if a specific IOVA is mapped by the guest using a large page, and adjust the size when notifying UNMAP events. When unmapping a large page, the information in the guest PTE encoding the page size is lost, since the guest clears the PTE before issuing the invalidation command to the IOMMU. In such case, the size of the original mapping can be retrieved from the iova_tree and used to issue the UNMAP notification. Using the correct size is essential since the VFIO IOMMU Type1v2 driver in the host kernel will reject unmap requests that do not fully cover previous mappings. Signed-off-by: Alejandro Jimenez <alejandro.j.jimenez@oracle.com> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Message-ID: <20250919213515.917111-12-alejandro.j.jimenez@oracle.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
2025-10-05amd_iommu: Sync shadow page tables on page invalidationAlejandro Jimenez1-8/+74
When the guest issues an INVALIDATE_IOMMU_PAGES command, decode the address and size of the invalidation and sync the guest page table state with the host. This requires walking the guest page table and calling notifiers registered for address spaces matching the domain ID encoded in the command. Signed-off-by: Alejandro Jimenez <alejandro.j.jimenez@oracle.com> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Message-ID: <20250919213515.917111-11-alejandro.j.jimenez@oracle.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
2025-10-05amd_iommu: Add basic structure to support IOMMU notifier updatesAlejandro Jimenez2-0/+23
Add the minimal data structures required to maintain a list of address spaces (i.e. devices) with registered notifiers, and to update the type of events that require notifications. Note that the ability to register for MAP notifications is not available. It will be unblocked by following changes that enable the synchronization of guest I/O page tables with host IOMMU state, at which point an amd-iommu device property will be introduced to control this capability. Signed-off-by: Alejandro Jimenez <alejandro.j.jimenez@oracle.com> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Message-ID: <20250919213515.917111-10-alejandro.j.jimenez@oracle.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
2025-10-05amd_iommu: Add a page walker to sync shadow page tables on invalidationAlejandro Jimenez1-0/+80
For the specified address range, walk the page table identifying regions as mapped or unmapped and invoke registered notifiers with the corresponding event type. Signed-off-by: Alejandro Jimenez <alejandro.j.jimenez@oracle.com> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Message-ID: <20250919213515.917111-9-alejandro.j.jimenez@oracle.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
2025-10-05amd_iommu: Add helpers to walk AMD v1 Page Table formatAlejandro Jimenez2-0/+163
The current amdvi_page_walk() is designed to be called by the replay() method. Rather than drastically altering it, introduce helpers to fetch guest PTEs that will be used by a page walker implementation. Signed-off-by: Alejandro Jimenez <alejandro.j.jimenez@oracle.com> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Message-ID: <20250919213515.917111-8-alejandro.j.jimenez@oracle.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
2025-10-05amd_iommu: Return an error when unable to read PTE from guest memoryAlejandro Jimenez1-2/+2
Make amdvi_get_pte_entry() return an error value (-1) in cases where the memory read fails, versus the current return of 0 to indicate failure. The reason is that 0 is also a valid value to have stored in the PTE in guest memory i.e. the guest does not have a mapping. Before this change, amdvi_get_pte_entry() returned 0 for both an error and for empty PTEs, but the page walker implementation that will be introduced in upcoming changes needs a method to differentiate between the two scenarios. Signed-off-by: Alejandro Jimenez <alejandro.j.jimenez@oracle.com> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Message-ID: <20250919213515.917111-7-alejandro.j.jimenez@oracle.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
2025-10-05amd_iommu: Add helper function to extract the DTEAlejandro Jimenez1-6/+42
Extracting the DTE from a given AMDVIAddressSpace pointer structure is a common operation required for syncing the shadow page tables. Implement a helper to do it and check for common error conditions. Signed-off-by: Alejandro Jimenez <alejandro.j.jimenez@oracle.com> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Message-ID: <20250919213515.917111-6-alejandro.j.jimenez@oracle.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
2025-10-05amd_iommu: Helper to decode size of page invalidation commandAlejandro Jimenez2-0/+38
The size of the region to invalidate depends on the S bit and address encoded in the command. Add a helper to extract this information, which will be used to sync shadow page tables in upcoming changes. Signed-off-by: Alejandro Jimenez <alejandro.j.jimenez@oracle.com> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Message-ID: <20250919213515.917111-5-alejandro.j.jimenez@oracle.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
2025-10-05amd_iommu: Reorder device and page table helpersAlejandro Jimenez1-86/+86
Move code related to Device Table and Page Table to an earlier location in the file, where it does not require forward declarations to be used by the various invalidation functions that will need to query the DTE and walk the page table in upcoming changes. This change consist of code movement only, no functional change intended. Signed-off-by: Alejandro Jimenez <alejandro.j.jimenez@oracle.com> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Message-ID: <20250919213515.917111-4-alejandro.j.jimenez@oracle.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
2025-10-05amd_iommu: Document '-device amd-iommu' common optionsAlejandro Jimenez1-0/+23
Document the common parameters used when emulating AMD vIOMMU. Besides the two amd-iommu specific options: 'xtsup' and 'dma-remap', the the generic x86 IOMMU option 'intremap' is also included, since it is typically specified in QEMU command line examples and mailing list threads. Signed-off-by: Alejandro Jimenez <alejandro.j.jimenez@oracle.com> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Message-ID: <20250919213515.917111-3-alejandro.j.jimenez@oracle.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
2025-10-05memory: Adjust event ranges to fit within notifier boundariesAlejandro Jimenez1-7/+3
Invalidating the entire address space (i.e. range of [0, ~0ULL]) is a valid and required operation by vIOMMU implementations. However, such invalidations currently trigger an assertion unless they originate from device IOTLB invalidations. Although in recent Linux guests this case is not exercised by the VTD implementation due to various optimizations, the assertion will be hit by upcoming AMD vIOMMU changes to support DMA address translation. More specifically, when running a Linux guest with VFIO passthrough device, and a kernel that does not contain commmit 3f2571fed2fa ("iommu/amd: Remove redundant domain flush from attach_device()"). Remove the assertion altogether and adjust the range to ensure it does not cross notifier boundaries. Signed-off-by: Alejandro Jimenez <alejandro.j.jimenez@oracle.com> Acked-by: Michael S. Tsirkin <mst@redhat.com> Acked-by: David Hildenbrand <david@redhat.com> Acked-by: Peter Xu <peterx@redhat.com> Message-Id: <20201116165506.31315-6-eperezma@redhat.com> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Message-ID: <20250919213515.917111-2-alejandro.j.jimenez@oracle.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
2025-10-05Add a feature for mapping a host unix socket to a guest tcp socketViktor Kurilko5-33/+100
This patch adds the ability to map a host unix socket to a guest tcp socket when using the slirp backend. This feature was added in libslirp version 4.7.0. A new syntax for unix socket: -hostfwd=unix:hostpath-[guestaddr]:guestport Signed-off-by: Viktor Kurilko <murlockkinght@gmail.com> Signed-off-by: Samuel Thibault <samuel.thibault@ens-lyon.org> Message-ID: <20250808143904.363907-1-murlockkinght@gmail.com>
2025-10-05pcie_sriov: make pcie_sriov_pf_exit() safe on non-SR-IOV devicesStefan Hajnoczi1-1/+5
Commit 3f9cfaa92c96 ("virtio-pci: Implement SR-IOV PF") added an unconditional call from virtio_pci_exit() to pcie_sriov_pf_exit(). pcie_sriov_pf_exit() reads from the SR-IOV Capability in Configuration Space: uint8_t *cfg = dev->config + dev->exp.sriov_cap; ... unparent_vfs(dev, pci_get_word(cfg + PCI_SRIOV_TOTAL_VF)); ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ This results in undefined behavior when dev->exp.sriov_cap is 0 because this is not an SR-IOV device. For example, unparent_vfs() segfaults when total_vfs happens to be non-zero. Fix this by returning early from pcie_sriov_pf_exit() when dev->exp.sriov_cap is 0 because this is not an SR-IOV device. Cc: Akihiko Odaki <odaki@rsg.ci.i.u-tokyo.ac.jp> Cc: Michael S. Tsirkin <mst@redhat.com> Reported-by: Qing Wang <qinwang@redhat.com> Buglink: https://issues.redhat.com/browse/RHEL-116443 Signed-off-by: Stefan Hajnoczi <stefanha@redhat.com> Reviewed-by: Akihiko Odaki <odaki@rsg.ci.i.u-tokyo.ac.jp> Fixes: cab1398a60eb ("pcie_sriov: Reuse SR-IOV VF device instances") Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Message-ID: <20250924155153.579495-1-stefanha@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
2025-10-05tests/virtio-scsi: add a virtio_error() IOThread testStefan Hajnoczi1-0/+32
Now that virtio_error() calls should work in an IOThread, add a virtio-scsi IOThread test cases that triggers virtio_error(). Signed-off-by: Stefan Hajnoczi <stefanha@redhat.com> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Message-ID: <20250922220149.498967-6-stefanha@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
2025-10-05tests/libqos: extract qvirtqueue_set_avail_idx()Stefan Hajnoczi2-4/+14
Setting the vring's avail.idx can be useful for low-level VIRTIO tests, especially for testing error scenarios with invalid vrings. Extract it into a new function so that the next commit can add a test that uses this new test API. Signed-off-by: Stefan Hajnoczi <stefanha@redhat.com> Acked-by: Fabiano Rosas <farosas@suse.de> Reviewed-by: Philippe Mathieu-Daudé <philmd@linaro.org> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Message-ID: <20250922220149.498967-5-stefanha@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
2025-10-05virtio: support irqfd in virtio_notify_config()Stefan Hajnoczi1-1/+6
virtio_error() calls virtio_notify_config() to inject a VIRTIO Configuration Change Notification. This doesn't work from IOThreads because the BQL is not held and the interrupt code path requires the BQL. Follow the same approach as virtio_notify() and use ->config_notifier (an irqfd) when called from the IOThread. Signed-off-by: Stefan Hajnoczi <stefanha@redhat.com> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Message-ID: <20250922220149.498967-4-stefanha@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
2025-10-05virtio: unify virtio_notify_irqfd() and virtio_notify()Stefan Hajnoczi5-27/+15
The difference between these two functions: - virtio_notify() uses the interrupt code path (MSI or classic IRQs) - virtio_notify_irqfd() uses guest notifiers (irqfds) virtio_notify() can only be called with the BQL held because the interrupt code path requires the BQL. Device models use virtio_notify_irqfd() from IOThreads since the BQL is not held. The two functions can be unified by pushing down the if (qemu_in_iothread()) check from virtio-blk and virtio-scsi into core virtio code. This is in preparation for the next commit that will add irqfd support to virtio_notify_config() and where it's unattractive to introduce another irqfd-only API for device model callers. Signed-off-by: Stefan Hajnoczi <stefanha@redhat.com> Reviewed-by: Philippe Mathieu-Daudé <philmd@linaro.org> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Message-ID: <20250922220149.498967-3-stefanha@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
2025-10-05vhost: use virtio_config_get_guest_notifier()Stefan Hajnoczi1-4/+7
There is a getter function so avoid accessing the ->config_notifier field directly. Signed-off-by: Stefan Hajnoczi <stefanha@redhat.com> Reviewed-by: Philippe Mathieu-Daudé <philmd@linaro.org> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Message-ID: <20250922220149.498967-2-stefanha@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
2025-10-05x86: ich9: fix default value of 'No Reboot' bit in GCSIgor Mammedov2-2/+7
[2] initialized 'No Reboot' bit to 1 by default. And due to quirk it happened to work with linux iTCO_wdt driver (which clears it on module load). However spec [1] states: " R/W. This bit is set when the “No Reboot” strap (SPKR pin on ICH9) is sampled high on PWROK. " So it should be set only when '-global ICH9-LPC.noreboot=true' and cleared when it's false (which should be default). Fix it to behave according to spec and set 'No Reboot' bit only when '-global ICH9-LPC.noreboot=true'. 1) Intel I/O Controller Hub 9 (ICH9) Family Datasheet (rev: 004) 2) Fixes: 920557971b6 (ich9: add TCO interface emulation) Signed-off-by: Igor Mammedov <imammedo@redhat.com> Tested-by: Daniel P. Berrangé <berrange@redhat.com> Reviewed-by: Daniel P. Berrangé <berrange@redhat.com> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Message-ID: <20250922132600.562193-1-imammedo@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
2025-10-05intel_iommu: Add PRI operations supportCLEMENT MATHIEU--DRIF3-0/+277
Implement the PRI callbacks in vtd_iommu_ops. Signed-off-by: Clement Mathieu--Drif <clement.mathieu--drif@eviden.com> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Message-ID: <20250901111630.1018573-6-clement.mathieu--drif@eviden.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
2025-10-05intel_iommu: Declare registers for PRICLEMENT MATHIEU--DRIF1-0/+55
Signed-off-by: Clement Mathieu--Drif <clement.mathieu--drif@eviden.com> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Message-ID: <20250901111630.1018573-5-clement.mathieu--drif@eviden.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
2025-10-05intel_iommu: Declare PRI constants and structuresCLEMENT MATHIEU--DRIF1-0/+49
Signed-off-by: Clement Mathieu--Drif <clement.mathieu--drif@eviden.com> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Message-ID: <20250901111630.1018573-4-clement.mathieu--drif@eviden.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
2025-10-05intel_iommu: Bypass barrier wait descriptorCLEMENT MATHIEU--DRIF1-1/+7
wait_desc with SW=0,IF=0,FN=1 must not be considered as an invalid descriptor as it is used to implement section 7.10 of the VT-d spec. Signed-off-by: Clement Mathieu--Drif <clement.mathieu--drif@eviden.com> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Message-ID: <20250901111630.1018573-3-clement.mathieu--drif@eviden.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
2025-10-05pcie: Add a way to get the outstanding page request allocation (pri) from ↵CLEMENT MATHIEU--DRIF2-0/+9
the config space. Signed-off-by: Clement Mathieu--Drif <clement.mathieu--drif@eviden.com> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Message-ID: <20250901111630.1018573-2-clement.mathieu--drif@eviden.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
2025-10-05smbios: cap DIMM size to 2Tb as workaround for broken WindowsIgor Mammedov4-1/+7
With current limit set to match max spec size (2PTb), Windows fails to parse type 17 records when DIMM size reaches 4Tb+. Failure happens in GetPhysicallyInstalledSystemMemory() function, and fails "Check SMBIOS System Memory Tables" SVVP test. Though not fatal, it might cause issues for userspace apps, something like [1]. Lets cap default DIMM size to 2Tb for now, until MS fixes it. 1) https://issues.redhat.com/browse/RHEL-81999?focusedId=27731200&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-27731200 PS: It's obvious 32 int overflow math somewhere in Windows, MS admitted that it's Windows bug and in a process of fixing it. However it's unclear if W10 and earlier would get the fix. So however I dislike changing defaults, we heed to work around the issue (it looks like QEMU regression while not being it). Hopefully 2Tb/DIMM split will last longer until VM memory size will become large enough to cause to many type 17 records issue again. PPS: Alternatively, instead of messing with defaults, we can create a dedicated knob to ask for desired DIMM size cap explicitly on CLI. That will let users to enable workaround when they hit this corner case. Downside is that knob has to be propagated up all mgmt stack, which might be not desirable. PPPS: Yet alternatively, users can configure initial RAM to be less than 4Tb and all additional RAM add as DIMMs on QEMU CLI. (however it's the job to be done by mgmt which could know Windows version and total amount of RAM) Signed-off-by: Igor Mammedov <imammedo@redhat.com> Fixes: 62f182c97b ("smbios: make memory device size configurable per Machine") Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Message-ID: <20250901084915.2607632-1-imammedo@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
2025-10-05hw/virtio: rename vhost-user-device and make user creatableAlex Bennée6-32/+26
We didn't make the device user creatable in the first place because we were worried users might get confused. Rename the device to make its nature as a test device even more explicit. While we are at it add a Kconfig variable so it can be skipped for those that want to thin out their build configuration even further. Acked-by: Stefano Garzarella <sgarzare@redhat.com> Reviewed-by: Manos Pitsidianakis <manos.pitsidianakis@linaro.org> Reviewed-by: Stefan Hajnoczi <stefanha@redhat.com> Signed-off-by: Alex Bennée <alex.bennee@linaro.org> Message-ID: <20250820195632.1956795-1-alex.bennee@linaro.org> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Message-ID: <20250901105948.982583-1-alex.bennee@linaro.org> Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
2025-10-05pcie_sriov: Fix broken MMIO accesses from SR-IOV VFsDamien Bergamini6-29/+8
Starting with commit cab1398a60eb, SR-IOV VFs are realized as soon as pcie_sriov_pf_init() is called. Because pcie_sriov_pf_init() must be called before pcie_sriov_pf_init_vf_bar(), the VF BARs types won't be known when the VF realize function calls pcie_sriov_vf_register_bar(). This breaks the memory regions of the VFs (for instance with igbvf): $ lspci ... Region 0: Memory at 281a00000 (64-bit, prefetchable) [virtual] [size=16K] Region 3: Memory at 281a20000 (64-bit, prefetchable) [virtual] [size=16K] $ info mtree ... address-space: pci_bridge_pci_mem 0000000000000000-ffffffffffffffff (prio 0, i/o): pci_bridge_pci 0000000081a00000-0000000081a03fff (prio 1, i/o): igbvf-mmio 0000000081a20000-0000000081a23fff (prio 1, i/o): igbvf-msix and causes MMIO accesses to fail: Invalid write at addr 0x281A01520, size 4, region '(null)', reason: rejected Invalid read at addr 0x281A00C40, size 4, region '(null)', reason: rejected To fix this, VF BARs are now registered with pci_register_bar() which has a type parameter and pcie_sriov_vf_register_bar() is removed. Fixes: cab1398a60eb ("pcie_sriov: Reuse SR-IOV VF device instances") Signed-off-by: Damien Bergamini <damien.bergamini@eviden.com> Signed-off-by: Clement Mathieu--Drif <clement.mathieu--drif@eviden.com> Reviewed-by: Akihiko Odaki <odaki@rsg.ci.i.u-tokyo.ac.jp> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Message-ID: <20250901151314.1038020-1-clement.mathieu--drif@eviden.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
2025-10-05hw/i386/pc: Avoid overlap between CXL window and PCI 64bit BARs in QEMUpeng guo1-9/+11
When using a CXL Type 3 device together with a virtio 9p device in QEMU on a physical server, the 9p device fails to initialize properly. The kernel reports the following error: virtio: device uses modern interface but does not have VIRTIO_F_VERSION_1 9pnet_virtio virtio0: probe with driver 9pnet_virtio failed with error -22 Further investigation revealed that the 64-bit BAR space assigned to the 9pnet device was overlapped by the memory window allocated for the CXL devices. As a result, the kernel could not correctly access the BAR region, causing the virtio device to malfunction. An excerpt from /proc/iomem shows: 480010000-cffffffff : CXL Window 0 480010000-4bfffffff : PCI Bus 0000:00 4c0000000-4c01fffff : PCI Bus 0000:0c 4c0000000-4c01fffff : PCI Bus 0000:0d 4c0200000-cffffffff : PCI Bus 0000:00 4c0200000-4c0203fff : 0000:00:03.0 4c0200000-4c0203fff : virtio-pci-modern To address this issue, this patch adds the reserved memory end calculation for cxl devices to reserve sufficient address space and ensure that CXL memory windows are allocated beyond all PCI 64-bit BARs. This prevents overlap with 64-bit BARs regions such as those used by virtio or other pcie devices, resolving the conflict. QEMU Build Configuration: ./configure --prefix=/home/work/qemu_master/build/ \ --target-list=x86_64-softmmu \ --enable-kvm \ --enable-virtfs QEMU Boot Command: sudo /home/work/qemu_master/qemu/build/qemu-system-x86_64 \ -nographic -machine q35,cxl=on -enable-kvm -m 16G -smp 8 \ -hda /home/work/gp_qemu/rootfs.img \ -virtfs local,path=/home/work/gp_qemu/share,mount_tag=host0,security_model=passthrough,id=host0 \ -kernel /home/work/linux_output/arch/x86/boot/bzImage \ --append "console=ttyS0 crashkernel=256M root=/dev/sda rootfstype=ext4 rw loglevel=8" \ -object memory-backend-ram,id=vmem0,share=on,size=4096M \ -device pxb-cxl,bus_nr=12,bus=pcie.0,id=cxl.1 \ -device cxl-rp,port=0,bus=cxl.1,id=root_port13,chassis=0,slot=2 \ -device cxl-type3,bus=root_port13,volatile-memdev=vmem0,id=cxl-vmem0,sn=0x123456789 \ -M cxl-fmw.0.targets.0=cxl.1,cxl-fmw.0.size=4G Fixes: 03b39fcf64bc ("hw/cxl: Make the CXL fixed memory window setup a machine parameter") Signed-off-by: peng guo <engguopeng@buaa.edu.cn> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Message-ID: <20250805142300.15226-1-engguopeng@buaa.edu.cn> Signed-off-by: Michael S. Tsirkin <mst@redhat.com>