Eugenio Pérez [Wed, 4 Mar 2026 17:35:31 +0000 (18:35 +0100)]
vhost: factor out the descriptor next fetching
The next field will not be used if IN_ORDER is enabled.
Signed-off-by: Eugenio Pérez <eperezma@redhat.com> Acked-by: Jason Wang <jasowang@redhat.com> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
Message-Id: <20260304173535.2702587-4-eperezma@redhat.com>
Eugenio Pérez [Wed, 4 Mar 2026 17:35:30 +0000 (18:35 +0100)]
vhost: move svq next desc array to descs state struct
It's the right place for it as it is part of the descriptor state. We
save the memory management of the array, and make the code changes of
the next patches easier.
Signed-off-by: Eugenio Pérez <eperezma@redhat.com> Acked-by: Jason Wang <jasowang@redhat.com> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
Message-Id: <20260304173535.2702587-3-eperezma@redhat.com>
Eugenio Pérez [Wed, 4 Mar 2026 17:35:29 +0000 (18:35 +0100)]
virtio: Allow to fill a whole virtqueue in order
As the while steps < max_steps is already one less than the vq size, the
right maximum max_steps variable is queue length, not the maximum
possible remainder of % vq->vring.num.
Fixes: b44135daa37 ("virtio: virtqueue_ordered_fill - VIRTIO_F_IN_ORDER support") Signed-off-by: Eugenio Pérez <eperezma@redhat.com> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
Message-Id: <20260304173535.2702587-2-eperezma@redhat.com>
Eugenio Pérez [Wed, 4 Mar 2026 17:38:57 +0000 (18:38 +0100)]
net/vhost-vdpa: enable vqs before DRIVER_OK if no cvq
VDUSE do not forward the enable message to the userland device at the
moment, leaving the dataplane disabled. As there is no functional
difference if the device have no CVQ, enable them before DRIVER_OK in
that case.
For devices with a control vq, keep the enabling of the dataplane after
CVQ so QEMU can restore the device configuration.
Signed-off-by: Eugenio Pérez <eperezma@redhat.com> Fixes: 6c4825476a43 ("vdpa: move vhost_vdpa_set_vring_ready to the caller") Acked-by: Jason Wang <jasowang@redhat.com> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
Message-Id: <20260304173857.2705296-1-eperezma@redhat.com>
There are two small issues in PCIEXBAR address mask handling:
- wrong bit positions for address mask bits (see PCIEXBAR description
in Q35 datasheet)
- incorrect usage of 64ADR_MASK
Due to this, attempting to write a valid PCIEXBAR address may cause it
to shift to another address, causing memory layout corruption where
emulated MMIO regions may overlap real (passed through) MMIO ranges. Fix
this by providing correct values.
Fixes: df2d8b3ed4 ("q35: Introduce q35 pc based chipset emulator") Signed-off-by: Alexey Gerasimenko <x1917x@gmail.com> Signed-off-by: Thierry Escande <thierry.escande@vates.tech> Reviewed-by: Michael S. Tsirkin <mst@redhat.com>
Message-Id: <20260313164649.794591-4-thierry.escande@vates.tech> Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
Kuan-Wei Chiu [Sun, 15 Mar 2026 23:10:47 +0000 (23:10 +0000)]
vhost-user: Fix stale error logs and return values in teardown paths
Commit bc85aae42045 ("vhost-user: return failure if backend crash when
live migration") refactored the set_guest_notifiers error handling but
introduced two regressions across multiple vhost devices.
By moving the function call directly into the if condition, the
subsequent error_report prints the stale ret variable instead of the
actual error code. Additionally, the refactoring hardcoded a return
value of -1 rather than propagating the true error status to the
caller.
Fix these issues by storing the set_guest_notifiers result in a local
err variable.
Fixes: bc85aae42045 ("vhost-user: return failure if backend crash when live migration") Signed-off-by: Kuan-Wei Chiu <visitorckw@gmail.com> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
Message-Id: <20260315231047.310029-1-visitorckw@gmail.com>
Aditya Gupta [Thu, 26 Mar 2026 19:04:38 +0000 (00:34 +0530)]
hw/pci: Replace assert with bounds check and return
As reported in https://gitlab.com/qemu-project/qemu/-/work_items/3334,
callers of 'pci_host_config_{read,write}_common' can pass length as 8,
causing an assert failure
The original issue with pnv_phb3 triggering the assert was fixed in a
previous commit
Instead of asserting on invalid length, check if the length is valid
(<=4), otherwise return (with the failure error code in read)
Reported-by: Zexiang Zhang <chan9yan9@gmail.com> Signed-off-by: Aditya Gupta <adityag@linux.ibm.com> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
Message-Id: <20260326190438.734239-3-adityag@linux.ibm.com>
Max Makarov [Tue, 31 Mar 2026 13:47:21 +0000 (16:47 +0300)]
vhost-user-blk: do not force VIRTIO_BLK_F_SIZE_MAX
vhost_user_blk_get_features() unconditionally advertises
VIRTIO_BLK_F_SIZE_MAX regardless of what the backend reports in
its config. The built-in QSD vhost-user-blk backend sets
size_max=0, creating a contradictory state where the feature bit
tells the guest that size_max is valid but the value is zero.
The in-process virtio-blk device does not advertise
VIRTIO_BLK_F_SIZE_MAX (it also sets size_max=0 in config), so
guests never see this contradiction with native virtio-blk.
Linux tolerates size_max=0 because blk_validate_limits() silently
corrects max_segment_size=0 to BLK_MAX_SEGMENT_SIZE (65536).
Windows viostor, however, trusts the feature bit and uses the raw
size_max=0 in its scatter-gather calculations, producing
zero-length segments that hang I/O. The disk appears empty to
Windows (no GPT, no partitions), causing INACCESSIBLE_BOOT_DEVICE.
Stop force-adding VIRTIO_BLK_F_SIZE_MAX in the frontend. The
feature remains in user_feature_bits[], so backends that properly
advertise it with a valid config value will still work.
Signed-off-by: Max Makarov <maxpain@linux.com> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
Message-Id: <20260331134721.96047-1-maxpain@linux.com>
Max Makarov [Tue, 31 Mar 2026 15:28:56 +0000 (18:28 +0300)]
vhost-user-blk-server: do not advertise VIRTIO_BLK_F_SIZE_MAX with size_max=0
The QSD vhost-user-blk backend advertises VIRTIO_BLK_F_SIZE_MAX but
sets size_max=0 in config, creating a contradictory state. The feature
bit tells the guest that size_max is valid, but the value is zero.
Windows viostor trusts the feature bit, reads size_max=0, and uses it
in scatter-gather calculations producing zero-length segments that hang
I/O. The disk appears empty (no GPT, no partitions), causing
INACCESSIBLE_BOOT_DEVICE BSOD. Linux tolerates this because
blk_validate_limits() silently corrects max_segment_size=0 to
BLK_MAX_SEGMENT_SIZE (65536).
This affects any VMM using QSD as a vhost-user-blk backend (QEMU,
Cloud Hypervisor, etc.), since both pass through SIZE_MAX from the
backend to the guest via feature intersection.
Remove VIRTIO_BLK_F_SIZE_MAX from the backend feature bits. The
size_max config field remains zero but is now ignored by guests since
the feature is not negotiated.
Signed-off-by: Max Makarov <maxpain@linux.com> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
Message-Id: <20260331152856.1802-1-maxpain@linux.com>
amd_iommu: Reject non-decreasing NextLevel in fetch_pte()
The AMD-Vi specification requires that the NextLevel field for a page table
entry must not be greater or equal to the current page table entry level.
Enforce this to avoid infinite page walk loops on corrupted or buggy guest
page tables.
The initial implementation of fetch_pte() did not implement this check, but
was not vulnerable since the page walk code explicitly decremented the level
instead of retrieving it from the page table entry.
Cc: qemu-stable@nongnu.org Reviewed-by: Sairaj Kodilkar <sarunkod@amd.com> Signed-off-by: Alejandro Jimenez <alejandro.j.jimenez@oracle.com> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
Message-Id: <20260330212817.992673-3-alejandro.j.jimenez@oracle.com>
amd_iommu: Follow root pointer before page walk and use 1-based levels
DTE[Mode] and PTE NextLevel encode page table levels as 1-based values, but
fetch_pte() currently uses a 0-based level counter, making the logic
harder to follow and requiring conversions between DTE mode and level.
Switch the page table walk logic to use 1-based level accounting in
fetch_pte() and the relevant macro helpers. To further simplify the page
walking loop, split the root page table access from the walk i.e. rework
fetch_pte() to follow the DTE Page Table Root Pointer and retrieve the top
level pagetable entry before entering the loop, then iterate only over the
PDE/PTE entries.
The reworked algorithm fixes a page walk bug where the page size was
calculated for the next level before checking if the current PTE was already
a leaf/hugepage. That caused hugepage mappings to be reported as 4K pages,
leading to performance degradation and failures in some setups.
Fixes: a74bb3110a5b ("amd_iommu: Add helpers to walk AMD v1 Page Table format") Cc: qemu-stable@nongnu.org Reported-by: David Hoppenbrouwers <qemu@demindiro.com> Reviewed-By: David Hoppenbrouwers <qemu@demindiro.com> Reviewed-by: Sairaj Kodilkar <sarunkod@amd.com> Signed-off-by: Alejandro Jimenez <alejandro.j.jimenez@oracle.com> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
Message-Id: <20260330212817.992673-2-alejandro.j.jimenez@oracle.com>
vhost-user.rst: Explicitly allow front-end to write to kick FDs
Migration of back-end state happens while the device is suspended (i.e
all vrings are stopped). To resume normal operation on the destination,
the vrings need to be started again with a kick (either a write on the
FD or the VHOST_USER_VRING_KICK in-band message if negotiated). While
these notifications are typically sent by the driver, it has no reason
to send them in the destination if it already sent them in the source as
the driver is unaware that a migration took place. Therefore it should
be the responsibility of the vhost-user front-end to ensure these vrings
are started. This is particularly necessary for queues where data only
flows from device to driver, such as those used by the vsock and input
devices.
This behavior is already used by some qemu vhost-user front-ends (e.g
vhost-user-blk) and by front-ends implemented on other VMMs(e.g CrosVm).
Adding it to the vhost-user documentation makes it explicit that this
strategy is permitted and suggest it to vhost-user front-end authors.
Explicitly documenting it is necessary because vring kicks appear
designed to originate in the driver, so having some originate in the
front-end can be counterintuitive and cause developers to waste time
looking for other alternatives or face pushback during code review.
Signed-off-by: Jorge E. Moreira <jemoreira@google.com> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
Message-Id: <20260411021205.3592118-1-jemoreira@google.com>
Jonathan Cameron [Wed, 15 Apr 2026 14:30:39 +0000 (15:30 +0100)]
MAINTAINERS: Update CXL maintainers entry including adding linux-cxl list
The CXL maintainers entry needs an update.
For a while convention has been to +CC linux-cxl@vger.kernel.org to get
better coverage for CXL aspects so formalize that with an L entry.
Drop Fan as he has not been at Samsung for a while now.
Switch my email address over to my kernel.org one.
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
Message-Id: <20260415143040.22223-1-Jonathan.Cameron@huawei.com>
libvduse: fix buffer overflow in vduse_queue_read_indirect_desc()
vduse_queue_read_indirect_desc() copies an indirect descriptor table
into a buffer in chunks when the table crosses a memory region
boundary. The destination is a struct vring_desc pointer but is
advanced by a byte count, so each increment moves the pointer by
read_len elements instead of read_len bytes, writing beyond the
buffer.
Use a char pointer for the destination so that the arithmetic
advances correctly.
While at it, change the source from a struct vring_desc pointer
to a void pointer: when the table is split across regions,
iova_to_va() can return a pointer into the middle of a descriptor,
so casting it to a struct vring_desc pointer is wrong. The pointer is
only used as a memcpy() source, so a void pointer is fine.
Fixes: CVE-2026-6425 Fixes: a6caeee811 ("libvduse: Add VDUSE (vDPA Device in Userspace) library") Cc: qemu-stable@nongnu.org Reported-by: DARKNAVY <vr@darknavy.com> Signed-off-by: Stefano Garzarella <sgarzare@redhat.com> 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>
Message-Id: <20260417132645.121192-3-sgarzare@redhat.com>
libvhost-user: fix buffer overflow in virtqueue_read_indirect_desc()
virtqueue_read_indirect_desc() copies an indirect descriptor table
into a buffer in chunks when the table crosses a memory region
boundary. The destination is a struct vring_desc pointer but is
advanced by a byte count, so each increment moves the pointer by
read_len elements instead of read_len bytes, writing beyond the
buffer.
Use a char pointer for the destination so that the arithmetic
advances correctly.
While at it, change the source from a struct vring_desc pointer
to a void pointer: when the table is split across regions,
vu_gpa_to_va() can return a pointer into the middle of a descriptor,
so casting it to a struct vring_desc pointer is wrong. The pointer is
only used as a memcpy() source, so a void pointer is fine.
Fixes: CVE-2026-6425 Fixes: 293084a719 ("libvhost-user: Support across-memory-boundary access") Cc: qemu-stable@nongnu.org Reported-by: DARKNAVY <vr@darknavy.com> Signed-off-by: Stefano Garzarella <sgarzare@redhat.com> 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>
Message-Id: <20260417132645.121192-2-sgarzare@redhat.com>
Unlike the kernel, vhost-user backend knows nothing about QEMU's
userspace addresses. We can pass GPA instead and nothing changes.
Generally, vhost-user servers need these addresses only to calculate
offsets inside memory regions. Still, some servers (QEMU's internal
is one example) may do checks for passed addresses to be "userspace
addresses", for example check for non-zero. That's why we need
additional negotiation for the feature.
The benefit: this opens the doors for further implementation of
local migration (live-update) with passing open vhost-related FDs
through UNIX domain socket. This way the connection with backend is
kept live and untouched.
Without this change, we would have to communicate with backend to
inform it about UVA address changes, but it's better to simply use
more stable GPA numbers, which don't change after migration.
Additionally, the current implementation exposes QEMU's process
address space by passing UVA, which breaks ASLR. New protocol
feature avoids that.
Note, that we do nothing with backend messages and replies.
Frontends have to work with backends userspace addresses anyway,
because they come from userfaultfd.
Signed-off-by: Vladimir Sementsov-Ogievskiy <vsementsov@yandex-team.ru> Reviewed-by: Michael S. Tsirkin <mst@redhat.com>
Based-on: <20260206095258.894504-1-vsementsov@yandex-team.ru> Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
Message-Id: <20260420202032.714884-11-vsementsov@yandex-team.ru>
Allow backends to chose, which addr to put into vhost_iotlb_msg:
user or physical. To be used in further commit.
Signed-off-by: Vladimir Sementsov-Ogievskiy <vsementsov@yandex-team.ru> Reviewed-by: Michael S. Tsirkin <mst@redhat.com>
Based-on: <20260206095258.894504-1-vsementsov@yandex-team.ru> Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
Message-Id: <20260420202032.714884-10-vsementsov@yandex-team.ru>
vhost: rename vring pointer fields to reflect user addresses
Rename vq->desc/avail/used to vq->desc_user/avail_user/used_user to
clearly indicate these fields contain user space addresses, not
physical addresses.
Signed-off-by: Vladimir Sementsov-Ogievskiy <vsementsov@yandex-team.ru> Reviewed-by: Michael S. Tsirkin <mst@redhat.com>
Based-on: <20260206095258.894504-1-vsementsov@yandex-team.ru> Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
Message-Id: <20260420202032.714884-9-vsementsov@yandex-team.ru>
vhost: stop reusing vq->desc (and friends) to store physical address
Remove the hack of storing physical addresses in vq->desc/avail/used
pointers when IOMMU is present. Instead, handle this case directly in
vhost_virtqueue_set_addr() by checking for IOMMU presence.
Signed-off-by: Vladimir Sementsov-Ogievskiy <vsementsov@yandex-team.ru> Reviewed-by: Michael S. Tsirkin <mst@redhat.com>
Based-on: <20260206095258.894504-1-vsementsov@yandex-team.ru> Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
Message-Id: <20260420202032.714884-8-vsementsov@yandex-team.ru>
qapi: remove user addresses from x-query-virtio-vhost-queue-status
Semantics of these (actually, internal) fields is not simple, they may
contain either virtual or physical addresses. We are going to change
this to simplify the logic. Keeping this logic only for unstable
info command seems too much. Changing semantics of info fields doesn't
seem to make real sense too. So, let's just drop them. We can dot it,
as command is experimental.
Signed-off-by: Vladimir Sementsov-Ogievskiy <vsementsov@yandex-team.ru> Acked-by: Markus Armbruster <armbru@redhat.com> Reviewed-by: Michael S. Tsirkin <mst@redhat.com>
Based-on: <20260206095258.894504-1-vsementsov@yandex-team.ru> Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
Message-Id: <20260420202032.714884-7-vsementsov@yandex-team.ru>
vhost: simplify vhost_memory_map() and vhost_memory_unmap()
Make these functions simple wrappers around address_space_map() and
address_space_unmap(). Move IOMMU handling logic one layer up to the
callers.
Signed-off-by: Vladimir Sementsov-Ogievskiy <vsementsov@yandex-team.ru> Reviewed-by: Michael S. Tsirkin <mst@redhat.com>
Based-on: <20260206095258.894504-1-vsementsov@yandex-team.ru> Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
Message-Id: <20260420202032.714884-6-vsementsov@yandex-team.ru>
vhost: replace .vhost_vq_get_addr() with .vhost_phys_vring_addr()
Make a simper handler to consolidate the logic in one place. That
helps further changes.
Signed-off-by: Vladimir Sementsov-Ogievskiy <vsementsov@yandex-team.ru> Reviewed-by: Michael S. Tsirkin <mst@redhat.com>
Based-on: <20260206095258.894504-1-vsementsov@yandex-team.ru> Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
Message-Id: <20260420202032.714884-5-vsementsov@yandex-team.ru>
This file is totally about vhost-kernel implementation, not generic
code. Let's finally give it corresponding name.
Signed-off-by: Vladimir Sementsov-Ogievskiy <vsementsov@yandex-team.ru> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
Message-Id: <20260420202032.714884-4-vsementsov@yandex-team.ru>
Most of handlers start from simply .vhost_, except for these
four, starting from .vhost_backend_. Let's rename them to be
consistent.
Signed-off-by: Vladimir Sementsov-Ogievskiy <vsementsov@yandex-team.ru> Reviewed-by: Michael S. Tsirkin <mst@redhat.com>
Based-on: <20260206095258.894504-1-vsementsov@yandex-team.ru> Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
Message-Id: <20260420202032.714884-3-vsementsov@yandex-team.ru>
vhost: move IOTLB functions from vhost-backend.c to vhost.c
Move and rename vhost_backend_update_device_iotlb(),
vhost_backend_invalidate_device_iotlb(), and
vhost_backend_handle_iotlb_msg() from vhost-backend.c to vhost.c.
vhost-backend.c is actually about vhost-kernel backend. But these
functions are shared with vhost-user, so let's move them into
generic place. Moreover, two of three functions becomes static as
they are used only in vhost.c.
Signed-off-by: Vladimir Sementsov-Ogievskiy <vsementsov@yandex-team.ru> Reviewed-by: Michael S. Tsirkin <mst@redhat.com>
Based-on: <20260206095258.894504-1-vsementsov@yandex-team.ru> Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
Message-Id: <20260420202032.714884-2-vsementsov@yandex-team.ru>
Signed-off-by: Vladimir Sementsov-Ogievskiy <vsementsov@yandex-team.ru> Reviewed-by: Daniil Tatianin <d-tatianin@yandex-team.ru> Reviewed-by: Raphael Norwitz <raphael.s.norwitz@gmail.com> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
Message-Id: <20260420200339.708640-23-vsementsov@yandex-team.ru>
Signed-off-by: Vladimir Sementsov-Ogievskiy <vsementsov@yandex-team.ru> Reviewed-by: Daniil Tatianin <d-tatianin@yandex-team.ru> Reviewed-by: Raphael Norwitz <raphael.s.norwitz@gmail.com> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Tested-by: Lei Yang <leiyang@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
Message-Id: <20260420200339.708640-22-vsementsov@yandex-team.ru>
Signed-off-by: Vladimir Sementsov-Ogievskiy <vsementsov@yandex-team.ru> Reviewed-by: Raphael Norwitz <raphael.s.norwitz@gmail.com> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
Message-Id: <20260420200339.708640-21-vsementsov@yandex-team.ru>
The logic kept as is. Refactor to simplify further changes.
Signed-off-by: Vladimir Sementsov-Ogievskiy <vsementsov@yandex-team.ru> Reviewed-by: Philippe Mathieu-Daudé <philmd@linaro.org> Reviewed-by: Raphael Norwitz <raphael.s.norwitz@gmail.com> Reviewed-by: Daniil Tatianin <d-tatianin@yandex-team.ru> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Tested-by: Lei Yang <leiyang@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
Message-Id: <20260420200339.708640-20-vsementsov@yandex-team.ru>
vhost: vhost_dev_init(): simplify features initialization
Drop extra variable and extra function parameter passing, initialize
dev._features directly.
Signed-off-by: Vladimir Sementsov-Ogievskiy <vsementsov@yandex-team.ru> Reviewed-by: Daniil Tatianin <d-tatianin@yandex-team.ru> Reviewed-by: Raphael Norwitz <raphael.s.norwitz@gmail.com> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
Message-Id: <20260420200339.708640-19-vsementsov@yandex-team.ru>
vhost: move busyloop timeout initialization to vhost_virtqueue_init()
Let's all per-virtqueue initializations be in one place.
Signed-off-by: Vladimir Sementsov-Ogievskiy <vsementsov@yandex-team.ru> Reviewed-by: Raphael Norwitz <raphael.s.norwitz@gmail.com> Reviewed-by: Daniil Tatianin <d-tatianin@yandex-team.ru> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Tested-by: Lei Yang <leiyang@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
Message-Id: <20260420200339.708640-18-vsementsov@yandex-team.ru>
No reason to rollback setting up busyloop timeout on failure.
We don't do such rollback for other things we setup in backend.
Also, look at vhost_net_init() in hw/net/vhost_net.c: we may fail
after successfully called vhost_dev_init(), and in this case we'll
just call vhost_dev_cleanup(), which doesn't rollback busyloop
timeout.
So, let's keep it simple.
Signed-off-by: Vladimir Sementsov-Ogievskiy <vsementsov@yandex-team.ru> Acked-by: Raphael Norwitz <raphael.s.norwitz@gmail.com> Reviewed-by: Daniil Tatianin <d-tatianin@yandex-team.ru> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Tested-by: Lei Yang <leiyang@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
Message-Id: <20260420200339.708640-17-vsementsov@yandex-team.ru>
vhost: final refactoring of vhost vrings map/unmap
Introduce helper functions vhost_vrings_map() and
vhost_vrings_unmap() and use them.
Signed-off-by: Vladimir Sementsov-Ogievskiy <vsementsov@yandex-team.ru> Reviewed-by: Raphael Norwitz <raphael.s.norwitz@gmail.com> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
Message-Id: <20260420200339.708640-16-vsementsov@yandex-team.ru>
vhost: vhost_virtqueue_start(): drop extra local variables
One letter named variables doesn't really help to read the code,
and they simply duplicate structure fields.
Signed-off-by: Vladimir Sementsov-Ogievskiy <vsementsov@yandex-team.ru> Reviewed-by: Raphael Norwitz <raphael.s.norwitz@gmail.com> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
Message-Id: <20260420200339.708640-15-vsementsov@yandex-team.ru>
vhost: move vrings mapping to the top of vhost_virtqueue_start()
This simplifies further refactoring and final introduction
of vhost backend live migration.
Signed-off-by: Vladimir Sementsov-Ogievskiy <vsementsov@yandex-team.ru> Reviewed-by: Raphael Norwitz <raphael.s.norwitz@gmail.com> Reviewed-by: Daniil Tatianin <d-tatianin@yandex-team.ru> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
Message-Id: <20260420200339.708640-14-vsementsov@yandex-team.ru>
No reason to calculate memory size again, as we have corresponding
variable for each vring.
Signed-off-by: Vladimir Sementsov-Ogievskiy <vsementsov@yandex-team.ru> Reviewed-by: Daniil Tatianin <d-tatianin@yandex-team.ru> Reviewed-by: Raphael Norwitz <raphael.s.norwitz@gmail.com> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Tested-by: Lei Yang <leiyang@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
Message-Id: <20260420200339.708640-13-vsementsov@yandex-team.ru>
This helps to simplify failure paths of vhost_virtqueue_start()
a lot. We also need to zero-out pointers on unmap, to not try
to unmap invalid pointers.
Signed-off-by: Vladimir Sementsov-Ogievskiy <vsementsov@yandex-team.ru> Reviewed-by: Daniil Tatianin <d-tatianin@yandex-team.ru> Reviewed-by: Raphael Norwitz <raphael.s.norwitz@gmail.com> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
Message-Id: <20260420200339.708640-12-vsementsov@yandex-team.ru>
We miss call to unmap in cases when vhost_memory_map() returns
lenght less than requested (still we consider such cases as an
error). Let's fix it in vhost_memory_map().
Fixes: c471ad0e9b ("vhost_net: device IOTLB support") Signed-off-by: Vladimir Sementsov-Ogievskiy <vsementsov@yandex-team.ru> Reviewed-by: Raphael Norwitz <raphael.s.norwitz@gmail.com> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
Message-Id: <20260420200339.708640-11-vsementsov@yandex-team.ru>
vhost-user: keep QIOChannelSocket for backend channel
Keep QIOChannelSocket pointer instead of more generic
QIOChannel. No real difference for now, but it would
be simpler to migrate socket fd in further commit.
Signed-off-by: Vladimir Sementsov-Ogievskiy <vsementsov@yandex-team.ru> Acked-by: Raphael Norwitz <raphael.s.norwitz@gmail.com> Reviewed-by: Daniil Tatianin <d-tatianin@yandex-team.ru> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Tested-by: Lei Yang <leiyang@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
Message-Id: <20260420200339.708640-10-vsementsov@yandex-team.ru>
virtio: drop *_set_guest_notifier_fd_handler() helpers
Now they don't make code more readable. Let's better put the whole
logic into virtio_queue_set_guest_notifier().
Signed-off-by: Vladimir Sementsov-Ogievskiy <vsementsov@yandex-team.ru> Reviewed-by: Daniil Tatianin <d-tatianin@yandex-team.ru> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
Message-Id: <20260420200339.708640-9-vsementsov@yandex-team.ru>
virtio: move common part of _set_guest_notifier to generic code
virtio-pci, virtio-mmio and virtio-ccw handle config notifier equally
but with different code (mmio adds a separate function, when pci use
common function). Let's chose the more compact way (pci) and reuse it
for mmio.
Signed-off-by: Vladimir Sementsov-Ogievskiy <vsementsov@yandex-team.ru> Acked-by: Eric Farman <farman@linux.ibm.com> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
Message-Id: <20260420200339.708640-8-vsementsov@yandex-team.ru>
It's hard to control where and how do we use this field. Let's
cover all usages by getters/setters, and keep direct access to the
field only in vhost.c. It will help to control migration of this
field in further commits.
Signed-off-by: Vladimir Sementsov-Ogievskiy <vsementsov@yandex-team.ru> Reviewed-by: Daniil Tatianin <d-tatianin@yandex-team.ru> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Tested-by: Lei Yang <leiyang@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
Message-Id: <20260420200339.708640-7-vsementsov@yandex-team.ru>
Obviously, this duplicated fragment doesn't make any sense.
Signed-off-by: Vladimir Sementsov-Ogievskiy <vsementsov@yandex-team.ru> Reviewed-by: Philippe Mathieu-Daudé <philmd@linaro.org> Reviewed-by: Raphael Norwitz <raphael.s.norwitz@gmail.com> Reviewed-by: Daniil Tatianin <d-tatianin@yandex-team.ru> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Tested-by: Lei Yang <leiyang@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
Message-Id: <20260420200339.708640-6-vsementsov@yandex-team.ru>
As comment says: it's only for vhost-user. So, let's move it
to corresponding vhost backend realization.
Signed-off-by: Vladimir Sementsov-Ogievskiy <vsementsov@yandex-team.ru> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
Message-Id: <20260420200339.708640-5-vsementsov@yandex-team.ru>
Signed-off-by: Vladimir Sementsov-Ogievskiy <vsementsov@yandex-team.ru> Reviewed-by: Daniil Tatianin <d-tatianin@yandex-team.ru> Reviewed-by: Raphael Norwitz <raphael.s.norwitz@gmail.com> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Tested-by: Lei Yang <leiyang@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
Message-Id: <20260420200339.708640-4-vsementsov@yandex-team.ru>
This field is mostly unused and sometimes confusing. We even have
a TODO-like comment to drop it, the comment is removed in this commit.
The field is used to held VHOST_USER_F_PROTOCOL_FEATURES for vhost-user
and/or VHOST_NET_F_VIRTIO_NET_HDR for vhost-net (which may be
vhost-user-net). But we can simply recalculate these two flags in place
from hdev->features, and from net-client for VHOST_NET_F_VIRTIO_NET_HDR.
Note: removing field from x-query-virtio-status result is incompatible
change. We can do it because the command is unstable.
Cc: devel@lists.libvirt.org Signed-off-by: Vladimir Sementsov-Ogievskiy <vsementsov@yandex-team.ru> Acked-by: Markus Armbruster <armbru@redhat.com> Reviewed-by: Daniil Tatianin <d-tatianin@yandex-team.ru> Acked-by: Raphael Norwitz <raphael.s.norwitz@gmail.com> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Tested-by: Lei Yang <leiyang@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
Message-Id: <20260420200339.708640-3-vsementsov@yandex-team.ru>
We call the handler almost the same way in three places:
- cryptodev-vhost.c
- vhost_net.c
- vhost.c
The only difference, is that in vhost.c we don't try to call the handler
for old vhost-user (when VHOST_USER_F_PROTOCOL_FEATURES is not supported).
cryptodev-vhost and vhost_net code will just fail in this case. Probably
they were developed only for newer vhost-user. Anyway, it doesn't seem
correct to rely on this error path, if these devices want to check,
that they don't communicate to old vhost-user protocol, they should
do that earlier.
Let's create the common helper, to call .vhost_set_vring_enable and
use in all three places. For vhost-user let's just always skip
enable/disable if it's unsupported.
Signed-off-by: Vladimir Sementsov-Ogievskiy <vsementsov@yandex-team.ru> Reviewed-by: Daniil Tatianin <d-tatianin@yandex-team.ru> Reviewed-by: Raphael Norwitz <raphael.s.norwitz@gmail.com> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Tested-by: Lei Yang <leiyang@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
Message-Id: <20260420200339.708640-2-vsementsov@yandex-team.ru>
Mark Cave-Ayland [Fri, 15 May 2026 15:05:47 +0000 (16:05 +0100)]
tests: data: update x86 ACPI tables
Update the x86 ACPI tables to reflect the IRQ descriptor changes for ISA serial
ports:
Device (COM1)
{
Name (_HID, EisaId ("PNP0501") /* 16550A-compatible COM Serial Port */) // _HID: Hardware ID
Name (_UID, One) // _UID: Unique ID
Name (_STA, 0x0F) // _STA: Status
Name (_CRS, ResourceTemplate () // _CRS: Current Resource Settings
{
IO (Decode16,
0x03F8, // Range Minimum
0x03F8, // Range Maximum
0x00, // Alignment
0x08, // Length
)
- IRQNoFlags ()
+ IRQ (Level, ActiveLow, Shared, )
{4}
})
}
Signed-off-by: Mark Cave-Ayland <mark.caveayland@nutanix.com> Acked-by: Ani Sinha <anisinha@redhat.com> Acked-by: Igor Mammedov <imammedo@redhat.com> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
Message-Id: <20260515150634.2637533-5-mark.caveayland@nutanix.com>
Mark Cave-Ayland [Fri, 15 May 2026 15:05:46 +0000 (16:05 +0100)]
hw/char/serial-isa.c: declare IRQ as shared in ACPI IRQ descriptor
From Windows 8.1 onwards ISA serial IRQs cannot be shared when ACPI Revision
3.0 is used in the FACP table. The reason for this is that if a 2-byte IRQ
Descriptor is used then the interrupt is considered to be high true, edge
sensitive, non-shareable. Since legacy serial ports COM1/3 and COM2/4 share
an IRQ then if more than 2 serial ports are added, Windows indicates a
conflict in Device Manager and these combinations cannot be used together.
Change the 2-byte IRQ Descriptor in the _CRS resource to a 3-byte IRQ
Descriptor indicating that the ISA serial IRQ is low true, level sensitive and
shareable. This enables all 4 legacy serial ports to be used in Windows without
conflict.
Note that it was agreed during the list discussion that this change does not
require a compatibility property since it is not part of the default machine
configuration and was already broken.
Signed-off-by: Mark Cave-Ayland <mark.caveayland@nutanix.com> Reviewed-by: Ani Sinha <anisinha@redhat.com> Reviewed-by: Igor Mammedov <imammedo@redhat.com> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
Message-Id: <20260515150634.2637533-4-mark.caveayland@nutanix.com>
Mark Cave-Ayland [Fri, 15 May 2026 15:05:45 +0000 (16:05 +0100)]
tests/acpi: allow DSDT acpi table changes
Signed-off-by: Mark Cave-Ayland <mark.caveayland@nutanix.com> Acked-by: Ani Sinha <anisinha@redhat.com> Acked-by: Igor Mammedov <imammedo@redhat.com> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
Message-Id: <20260515150634.2637533-3-mark.caveayland@nutanix.com>
Mark Cave-Ayland [Fri, 15 May 2026 15:05:44 +0000 (16:05 +0100)]
hw/acpi/aml-build.c: add aml_irq() representing the 3-byte IRQ descriptor
The existing aml_interrupt() uses the Extended Interrupt Descriptor to store
the interrupt information, however newer Windows will only parse the
standard IRQ Descriptor when enumerating ISA serial ports.
Signed-off-by: Mark Cave-Ayland <mark.caveayland@nutanix.com> Reviewed-by: Ani Sinha <anisinha@redhat.com> Reviewed-by: Igor Mammedov <imammedo@redhat.com> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
Message-Id: <20260515150634.2637533-2-mark.caveayland@nutanix.com>
Zhenzhong Duan [Wed, 27 May 2026 05:46:55 +0000 (01:46 -0400)]
intel_iommu: Expose flag VIOMMU_FLAG_PASID_SUPPORTED and VIOMMU_FLAG_WANT_PASID_ATTACH
VFIO device will check flag VIOMMU_FLAG_PASID_SUPPORTED and expose PASID
capability, also check VIOMMU_FLAG_WANT_PASID_ATTACH to enable pasid
attachment, without those guest could not enable PASID of this device even
if vIOMMU's pasid is configured.
We don't expose the two flags when fist stage translation is not configured
as we don't support shadow page table on a PASID.
This is the final knob to enable PASID.
Signed-off-by: Zhenzhong Duan <zhenzhong.duan@intel.com> Reviewed-by: Yi Liu <yi.l.liu@intel.com> Reviewed-by: Clement Mathieu--Drif <clement.mathieu--drif@bull.com> Tested-by: Xudong Hao <xudong.hao@intel.com> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
Message-Id: <20260527054658.1021096-18-zhenzhong.duan@intel.com>
Zhenzhong Duan [Wed, 27 May 2026 05:46:53 +0000 (01:46 -0400)]
intel_iommu_accel: Switch to VTDAccelPASIDCacheEntry for PASID bind/unbind and PIOTLB invalidation
This patch switches from VTDAddressSpace to VTDAccelPASIDCacheEntry for
handling PASID bind/unbind operations and PIOTLB invalidations in
passthrough scenarios. VTDAccelPASIDCacheEntry was introduced to cache
PASID entries for passthrough devices and is now ready to propagate
PASID bind/unbind operations and PIOTLB invalidations to the host.
Unlike the previous approach, VTDAccelPASIDCacheEntry supports both
IOMMU_NO_PASID (rid_pasid) and other valid PASIDs, so this switch drops
IOMMU_NO_PASID limitations that existed in the prior PASID bind/unbind
and PIOTLB invalidation path. For IOMMU_NO_PASID of passthrough devices,
VTDAddressSpace continues to handle shadow page modifications to the
host, but no longer manages PASID bind/unbind operations or PIOTLB
invalidations for passthrough scenarios.
Co-developed-by: Yi Liu <yi.l.liu@intel.com> Signed-off-by: Yi Liu <yi.l.liu@intel.com> Signed-off-by: Zhenzhong Duan <zhenzhong.duan@intel.com> Tested-by: Xudong Hao <xudong.hao@intel.com> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
Message-Id: <20260527054658.1021096-16-zhenzhong.duan@intel.com>
Zhenzhong Duan [Wed, 27 May 2026 05:46:52 +0000 (01:46 -0400)]
intel_iommu_accel: Handle PASID entry removal for system reset
When system level reset, DMA translation is turned off, all PASID
entries become stale and should be deleted.
vtd_hiod list is never accessed without BQL, so no need to guard with
iommu lock.
Signed-off-by: Zhenzhong Duan <zhenzhong.duan@intel.com> Reviewed-by: Yi Liu <yi.l.liu@intel.com> Tested-by: Xudong Hao <xudong.hao@intel.com> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
Message-Id: <20260527054658.1021096-15-zhenzhong.duan@intel.com>
Zhenzhong Duan [Wed, 27 May 2026 05:46:51 +0000 (01:46 -0400)]
intel_iommu_accel: Bypass PASID entry addition for just deleted entry
For VTD_INV_DESC_PASIDC_G_PASID_SI typed pc_inv_dsc invalidation, if an
pasid entry is just removed, it can never be a new entry to add. So
calling vtd_replay_pasid_bind_for_dev() is unnecessary.
Introduce a new field accel_pce_deleted in VTDPASIDCacheInfo to mark
this case and to do the bypassing.
Suggested-by: Yi Liu <yi.l.liu@intel.com> Signed-off-by: Zhenzhong Duan <zhenzhong.duan@intel.com> Reviewed-by: Yi Liu <yi.l.liu@intel.com> Tested-by: Xudong Hao <xudong.hao@intel.com> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
Message-Id: <20260527054658.1021096-14-zhenzhong.duan@intel.com>
Zhenzhong Duan [Wed, 27 May 2026 05:46:50 +0000 (01:46 -0400)]
intel_iommu_accel: Handle PASID entry removal for pc_inv_dsc request
When guest deletes PASID entries, QEMU will capture the pasid cache
invalidation request, walk through pasid_cache_list in each passthrough
device to find stale VTDAccelPASIDCacheEntry and delete them.
Co-developed-by: Yi Liu <yi.l.liu@intel.com> Signed-off-by: Yi Liu <yi.l.liu@intel.com> Signed-off-by: Zhenzhong Duan <zhenzhong.duan@intel.com> Tested-by: Xudong Hao <xudong.hao@intel.com> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
Message-Id: <20260527054658.1021096-13-zhenzhong.duan@intel.com>
Zhenzhong Duan [Wed, 27 May 2026 05:46:49 +0000 (01:46 -0400)]
intel_iommu_accel: Handle PASID entry addition for pc_inv_dsc request
Structure VTDAddressSpace includes some elements suitable for emulated
device and passthrough device without PASID, e.g., address space,
different memory regions, etc, it is also protected by vtd iommu lock,
all these are useless and become a burden for passthrough device with
PASID.
When there are lots of PASIDs used in one device, the AS and MRs are
all registered to memory core and impact the whole system performance.
So instead of using VTDAddressSpace to cache pasid entry for each pasid
of a passthrough device, we define a light weight structure
VTDAccelPASIDCacheEntry with only necessary elements for each pasid. We
will use this struct as a parameter to conduct binding/unbinding to
nested hwpt and to record the current bound nested hwpt. It's also
designed to support IOMMU_NO_PASID.
VTDAccelPASIDCacheEntry is designed to only be used in intel_iommu_accel.c,
similarly VTDPASIDCacheEntry should only be used in hw/i386/intel_iommu.c
When guest creates new PASID entries, QEMU will capture the pc_inv_dsc
(pasid cache invalidation) request, walk through each pasid in each
passthrough device for valid pasid entries, create a new
VTDAccelPASIDCacheEntry if not existing yet.
IOMMU_NO_PASID of passthrough device still need to register MRs in case
guest does not operate in scalable mode. So for IOMMU_NO_PASID, we have
both VTDPASIDCacheEntry and VTDAccelPASIDCacheEntry.
Co-developed-by: Yi Liu <yi.l.liu@intel.com> Signed-off-by: Yi Liu <yi.l.liu@intel.com> Signed-off-by: Zhenzhong Duan <zhenzhong.duan@intel.com> Tested-by: Xudong Hao <xudong.hao@intel.com> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
Message-Id: <20260527054658.1021096-12-zhenzhong.duan@intel.com>
Zhenzhong Duan [Wed, 27 May 2026 05:46:48 +0000 (01:46 -0400)]
intel_iommu: Refactor PASID processing to use IOMMU_NO_PASID internally
The PCI subsystem uses PCI_NO_PASID for requests-without-PASID, but VT-d
emulation uses IOMMU_NO_PASID internally (ecap.RPS==0). This leads to
conversion and checking code between PCI_NO_PASID and IOMMU_NO_PASID
throughout the implementation.
Refactor to use IOMMU PASID consistently within Intel IOMMU by storing
IOMMU PASID value in vtd_as->pasid. After this change, PCI_NO_PASID is
only used at three boundary points:
1. PCI_NO_PASID -> IOMMU_NO_PASID: Convert PCI PASID to IOMMU PASID in
vtd_find_add_as() and cache in vtd_as->pasid.
2. IOMMU_NO_PASID -> PCI_NO_PASID: Convert when notifying UNMAP events
via memory_region_notify_iommu() and returning IOMMUTLBEntry in
vtd_iommu_translate().
This eliminates conversion/checks in PASID table lookups, simplifies
invalidation logic with consistent PASID values, and improves code
readability. The PCI subsystem interface remains unchanged to maintain
compatibility with other IOMMU implementations that may not use PASID 0
for requests-without-PASID.
Suggested-by: Clement Mathieu--Drif <clement.mathieu--drif@bull.com> Signed-off-by: Zhenzhong Duan <zhenzhong.duan@intel.com> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
Message-Id: <20260527054658.1021096-11-zhenzhong.duan@intel.com>
Zhenzhong Duan [Wed, 27 May 2026 05:46:47 +0000 (01:46 -0400)]
intel_iommu: Use IOMMU_NO_PASID and delete PASID_0
In previous patch we introduced a global macro IOMMU_NO_PASID(0) for
the RID attachment, this makes the local macro PASID_0 redundant.
Delete it and use IOMMU_NO_PASID instead.
No functional changes intended.
Suggested-by: Yi Liu <yi.l.liu@intel.com> Signed-off-by: Zhenzhong Duan <zhenzhong.duan@intel.com> Reviewed-by: Yi Liu <yi.l.liu@intel.com> Reviewed-by: Clement Mathieu--Drif <clement.mathieu--drif@bull.com> Tested-by: Xudong Hao <xudong.hao@intel.com> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
Message-Id: <20260527054658.1021096-10-zhenzhong.duan@intel.com>
Zhenzhong Duan [Wed, 27 May 2026 05:46:46 +0000 (01:46 -0400)]
intel_iommu: Fix PASID validity check in fault reporting
The current code incorrectly uses "pasid != PCI_NO_PASID" to determine if
PASID should be reported in fault records. However, this check happens
after the code converts PCI_NO_PASID to PASID_0 in scalable mode.
This means that for requests that originally had PCI_NO_PASID, the check
"pasid != PCI_NO_PASID" will incorrectly return true (since pasid is now
PASID_0), causing fault records to incorrectly indicate PASID validity.
According to the VT-d specification, the PASID field in fault records is
only valid for Requests-with-PASID:
"When Set, indicates the faulted request has a PASID TLP Prefix."
Fix this by capturing the original PASID state before the PCI_NO_PASID to
PASID_0 conversion, ensuring fault records correctly reflect whether the
original request had a PASID.
Fixes: 1b2b12376c8a ("intel_iommu: process PASID-based iotlb invalidation") Suggested-by: Yi Liu <yi.l.liu@intel.com> Signed-off-by: Zhenzhong Duan <zhenzhong.duan@intel.com> Reviewed-by: Michael S. Tsirkin <mst@redhat.com>
Message-Id: <20260527054658.1021096-9-zhenzhong.duan@intel.com> Reviewed-by: Clement Mathieu--Drif <clement.mathieu--drif@bull.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
Zhenzhong Duan [Wed, 27 May 2026 05:46:45 +0000 (01:46 -0400)]
intel_iommu: Export some functions
Export some functions for accel code usages. Inline functions and MACROs
are moved to internal header files. Then accel code in following patches
could access them.
Signed-off-by: Zhenzhong Duan <zhenzhong.duan@intel.com> Reviewed-by: Clement Mathieu--Drif <clement.mathieu--drif@eviden.com> Reviewed-by: Yi Liu <yi.l.liu@intel.com> Tested-by: Xudong Hao <xudong.hao@intel.com> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
Message-Id: <20260527054658.1021096-8-zhenzhong.duan@intel.com>
Zhenzhong Duan [Wed, 27 May 2026 05:46:44 +0000 (01:46 -0400)]
intel_iommu: make vtd_dev_get_pe_from_pasid() more generic
Refactor vtd_dev_get_pe_from_pasid() to take individual parameters
(IntelIOMMUState, PCIBus, devfn, pasid) instead of VTDAddressSpace.
This makes the function more reusable and prepares it for export to be
used in the acceleration path. Remove inline qualifier as the function
will be exported in a subsequent patch.
No functional changes intended.
Suggested-by: Yi Liu <yi.l.liu@intel.com> Signed-off-by: Zhenzhong Duan <zhenzhong.duan@intel.com> Reviewed-by: Michael S. Tsirkin <mst@redhat.com>
Message-Id: <20260527054658.1021096-7-zhenzhong.duan@intel.com> Reviewed-by: Clement Mathieu--Drif <clement.mathieu--drif@bull.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
Zhenzhong Duan [Wed, 27 May 2026 05:46:43 +0000 (01:46 -0400)]
intel_iommu: Rename pasid property to "pasid-bits" and define it as type uint8
'x-pasid-mode' is a bool property, we need an extra 'pss' property to
represent PASID size supported. Because there is no any device in QEMU
supporting pasid capability yet, no guest could use the pasid feature
until now, 'x-pasid-mode' takes no effect.
So instead of an extra 'pss' property we can use a single property of
uint8 type and named 'pasid-bits' to represent if pasid is supported
and the PASID bits size. A value of N > 0 means pasid is supported and
N - 1 is the value in PSS field in ECAP register.
PASID bits size should also be no more than 20 bits according to PCI spec.
Signed-off-by: Zhenzhong Duan <zhenzhong.duan@intel.com> Reviewed-by: Clement Mathieu--Drif <clement.mathieu--drif@bull.com> Reviewed-by: Yi Liu <yi.l.liu@intel.com> Tested-by: Xudong Hao <xudong.hao@intel.com> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
Message-Id: <20260527054658.1021096-6-zhenzhong.duan@intel.com>
Zhenzhong Duan [Wed, 27 May 2026 05:46:42 +0000 (01:46 -0400)]
intel_iommu: Create the nested hwpt with IOMMU_HWPT_ALLOC_PASID flag
When pasid is enabled, any hwpt attached to non-PASID or PASID should be
IOMMU_HWPT_ALLOC_PASID flagged, or else attachment fails.
Change vtd_destroy_old_fs_hwpt() to pass in 'VTDHostIOMMUDevice *' for
naming consistency.
Signed-off-by: Zhenzhong Duan <zhenzhong.duan@intel.com> Reviewed-by: Clement Mathieu--Drif <clement.mathieu--drif@bull.com> Reviewed-by: Yi Liu <yi.l.liu@intel.com> Tested-by: Xudong Hao <xudong.hao@intel.com> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
Message-Id: <20260527054658.1021096-5-zhenzhong.duan@intel.com>
Zhenzhong Duan [Wed, 27 May 2026 05:46:41 +0000 (01:46 -0400)]
vfio/iommufd: Create nesting parent hwpt with IOMMU_HWPT_ALLOC_PASID flag
When both device and vIOMMU have PASID enabled, then guest may setup
pasid usages such as SVM.
VFIO needs to be aware of potential pasid usage and should attach the
non-pasid part of pasid-capable device to hwpt flagged with
IOMMU_HWPT_ALLOC_PASID.
ARM SMMU doesn't support IOMMU_HWPT_ALLOC_PASID, only VTD need it. So
we can't check the existing vIOMMU flag VIOMMU_FLAG_PASID_SUPPORTED to
determine if set flag IOMMU_HWPT_ALLOC_PASID. Instead, introduce a new
flag VIOMMU_FLAG_WANT_PASID_ATTACH which will only be exposed by VTD.
Opportunistically add documentation for VIOMMU_FLAG_PASID_SUPPORTED
and explain the difference with VIOMMU_FLAG_WANT_PASID_ATTACH.
Signed-off-by: Zhenzhong Duan <zhenzhong.duan@intel.com> Reviewed-by: Yi Liu <yi.l.liu@intel.com> Tested-by: Xudong Hao <xudong.hao@intel.com> Reviewed-by: Michael S. Tsirkin <mst@redhat.com>
Message-Id: <20260527054658.1021096-4-zhenzhong.duan@intel.com> Reviewed-by: Shameer Kolothum <skolothumtho@nvidia.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
Zhenzhong Duan [Wed, 13 May 2026 06:42:26 +0000 (02:42 -0400)]
intel_iommu: Change 'flts' property naming to 'fsts'
Previous patch Removed 'x-' prefix from 'x-flts' property.
Opportunistically, this patch does s/flts/fsts for property name
in order to better align with newer spec since revision 3.4 which
changed terminology from "First-level" to "First-stage".
Signed-off-by: Zhenzhong Duan <zhenzhong.duan@intel.com> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
Message-Id: <20260513064227.2304854-3-zhenzhong.duan@intel.com>
Zhenzhong Duan [Wed, 13 May 2026 06:42:25 +0000 (02:42 -0400)]
intel_iommu: Remove 'x-' prefix from 'x-scalable-mode' and 'x-flts' properties
We had 'x-scalable-mode' for more than 5 years and 'x-flts' for more than 1
year, it's fine to remove 'x-' now.
This is a prerequisite to enable intel_iommu's scalable mode and first stage
translation support in libvirt.
Signed-off-by: Zhenzhong Duan <zhenzhong.duan@intel.com> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
Message-Id: <20260513064227.2304854-2-zhenzhong.duan@intel.com>
Costas Argyris [Sat, 30 May 2026 18:34:51 +0000 (19:34 +0100)]
tests/qtest: Add amd-iommu command buffer head wrap test
Add a qtest for AMD IOMMU command buffer head pointer wraparound.
The test programs a command buffer, fills it with COMPLETION_WAIT commands,
advances the tail to consume all but the final entry, then wraps the tail
to zero to force the final command to advance CmdHeadPtr past the end of
the buffer. The guest-visible CmdHeadPtr register must then wrap back to zero.
This covers the case fixed by an earlier CmdHeadPtr wraparound patch.
The Linux kernel AMD IOMMU driver is not affected by this bug because it
uses COMPLETION_WAIT with a memory store doorbell to detect command progress.
Signed-off-by: Costas Argyris <costas.argyris@amd.com> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
Message-Id: <20260530183458.7778-1-costas.argyris@amd.com>
amd_iommu: Update command buffer head ptr in MMIO region after wraparound
When processing a command, amdvi_cmdbuf_run() increments cmdbuf_head and
writes it to the emulated MMIO register space before checking whether it
has reached the end of the command buffer.
If the incremented value reaches the end of the buffer and the tail pointer
is zero, the loop exits and the COMMAND_HEAD offset still contains an
unwrapped value. There are no errors in command processing since internal
cmdbuf_head state is always correctly updated, but the spec defines the
CmdHeadPtr field in MMIO Offset 2000h Command Buffer Head Pointer Register
as RW i.e. guest-visible, so it should be kept consistent.
Wrap cmdbuf_head before updating COMMAND_HEAD so the MMIO-visible register
always matches the internal command buffer head pointer position.
Cc: qemu-stable@nongnu.org Signed-off-by: Alejandro Jimenez <alejandro.j.jimenez@oracle.com> Reviewed-by: Sairaj Kodilkar <sarunkod@amd.com> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
Message-Id: <20260512150044.334867-1-alejandro.j.jimenez@oracle.com>
Paolo Bonzini [Mon, 11 May 2026 11:39:22 +0000 (13:39 +0200)]
amd_iommu: restrict command buffer head/tail ranges to ring size
The AMD IOMMU command buffer is a ring buffer of cmdbuf_len (a power
of two) entries. Each entry is 16 bytes and the head pointer cycles
through the set:
The tail pointer is written by the guest through the COMMAND_TAIL MMIO
register (offset 0x2008); the while loop in amdvi_cmdbuf_run() only
terminates when head == tail. If tail is set to a value higher than
cmdbuf_len * 16, head will cycle through all the elements of the ring
buffer indefinitely, without ever matching tail. Fix this by further
masking tail (and head, for consistency) against the size of the
ring buffer.
Reported-by: Yunhe Wang <yunhewwww@163.com> Cc: qemu-stable@nongnu.org Signed-off-by: Paolo Bonzini <pbonzini@redhat.com> Reviewed-by: Alejandro Jimenez <alejandro.j.jimenez@oracle.com> Reviewed-by: Michael S. Tsirkin <mst@redhat.com>
Message-Id: <20260511113923.2478812-1-pbonzini@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
Stefan Hajnoczi [Tue, 2 Jun 2026 15:34:55 +0000 (11:34 -0400)]
Merge tag 'pull-tpm-2026-06-01-1' of https://github.com/stefanberger/qemu-tpm into staging
Merge tpm 2026/06/01 v1
# -----BEGIN PGP SIGNATURE-----
#
# iQEzBAABCgAdFiEEuBi5yt+QicLVzsZrda1lgCoLQhEFAmod/1EACgkQda1lgCoL
# QhGFmwf/SDA8DQGekVksB+TiDV11a+2I8FzBHJmQ2RhKbSGxY77ZbWei+Z45fU9/
# 2e0aDizw7GDRPGthKChjOYA5SAVf7gwUaSkhv21xDNgsddcdCr05y1RljOfShtbw
# S55XOk6Tx2zX/00nTqskyw9bqz2YwnAh5vPjfDWy6TV5k7Q3BlMyooFeJu/19pU7
# RnMLfHdJHlYSQ2Bn4ZT6agXsoQIvnJK51Poq0TJQo0PW8kWFwcp13Ic+uyvRfkF3
# U6JdTGBXJxCHMgIkO4EG4o5PT7Dy8miKFepJCUgyjHesi7iFYQlIAnsJth9anMjL
# zoqnMVNN1jVrcuzVLG9oNHB7+hZ/Eg==
# =Wlez
# -----END PGP SIGNATURE-----
# gpg: Signature made Mon 01 Jun 2026 17:53:21 EDT
# gpg: using RSA key B818B9CADF9089C2D5CEC66B75AD65802A0B4211
# gpg: Good signature from "Stefan Berger <stefanb@linux.vnet.ibm.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: B818 B9CA DF90 89C2 D5CE C66B 75AD 6580 2A0B 4211
* tag 'pull-tpm-2026-06-01-1' of https://github.com/stefanberger/qemu-tpm:
tpm_emulator: Disconnect if response exceeds negotiated buffer size
tpm_emulator: Reject a buffer size different than what was requested
hw/tpm: Add support for VM migration with TPM CRB chunking
test/qtest: Add test for tpm crb chunking
hw/tpm: Implement TPM CRB chunking logic
hw/tpm: Add internal buffer state for chunking
hw/tpm: Refactor CRB_CTRL_START register access
hw/tpm: Add TPM CRB chunking fields
ui/vdagent: Use VMSTATE_GBYTEARRAY to safely migrate outbuf
migration/vmstate: Add VMState support for GByteArray
tests: Add a TPM TIS I2C swtpm test
tests: Check whether the I2C master flag is set
tests: Rename id of tpmdev to tpm0
tests: Convert string arrays to byte arrays
tests: Have TPM I2C read/write functions take QTestState as first parameter
tests: Move TPM I2C bus read/write functions to common files
Signed-off-by: Stefan Hajnoczi <stefanha@redhat.com>
Stefan Hajnoczi [Tue, 2 Jun 2026 15:34:42 +0000 (11:34 -0400)]
Merge tag 'pull-11.1-testing-hotfix-010626-1' of https://gitlab.com/stsquad/qemu into staging
testing updates:
- revert test/Makefile.include move due to regression
- work-around move with explicit targets for MacOS gitlab
- use debian-all-test-cross for MIPS TCG tests
# -----BEGIN PGP SIGNATURE-----
#
# iQEzBAABCgAdFiEEZoWumedRZ7yvyN81+9DbCVqeKkQFAmodsKwACgkQ+9DbCVqe
# KkQ8jQf/Xydd5C6H5WOjLMk0i+fbiiFeZUVZ0uIwWrWEjDNGVdbT575/bS39PKeh
# 2UTANzcePKP3VLsWYw8E/8fWSkdUFi47lGRZHjQN6cbPo7cC3NskkOTkumvE9Fr9
# NuGmbw2FVFnmn6xkZCYSHdj2MQeGf9dy9hyGlivTfsmj8ypw92uMzp1/vvfC5wH1
# la1RIPDRUngQmHK+PUQQTVdWgpWETier7QGqCyBWbk6Gc26O8L9xeiwR8Dhi+dPv
# 1cY8BvAWC+nOvDtCClahmEpTfiWALKtE8c+/EqP3QLCWDdAcUg7XGtTlX3iYIy+u
# 8nCt/HOpKynpuuxHrIoUs9q8FE9OuA==
# =SUZJ
# -----END PGP SIGNATURE-----
# gpg: Signature made Mon 01 Jun 2026 12:17:48 EDT
# gpg: using RSA key 6685AE99E75167BCAFC8DF35FBD0DB095A9E2A44
# gpg: Good signature from "Alex Bennée (Master Work Key) <alex.bennee@linaro.org>" [unknown]
# gpg: WARNING: This key is not certified with a trusted signature!
# gpg: There is no indication that the signature belongs to the owner.
# Primary key fingerprint: 6685 AE99 E751 67BC AFC8 DF35 FBD0 DB09 5A9E 2A44
* tag 'pull-11.1-testing-hotfix-010626-1' of https://gitlab.com/stsquad/qemu:
configure: use debian-all-test-cross for mipsel tcg tests
gitlab: work around the inability to build targets for MacOS
Revert "Makefile: include tests/Makefile.include before ninja calculation"
Signed-off-by: Stefan Hajnoczi <stefanha@redhat.com>
Stefan Berger [Mon, 11 May 2026 14:22:18 +0000 (14:22 +0000)]
tpm_emulator: Disconnect if response exceeds negotiated buffer size
Disconnect from the emulator if a response was to exceed the negotiated
buffer size.
The TPM TIS and SPAPR use 4096 bytes and the CRB 3968 bytes. There are
currently no TPM 2 responses using this size of a buffer and therefore
no response will be sent that is exceeding this size.
Stefan Berger [Mon, 11 May 2026 14:22:17 +0000 (14:22 +0000)]
tpm_emulator: Reject a buffer size different than what was requested
When the TIS, SPAPR, or CRB frontends negotiate a buffer size with the
TPM backend, then the tpm_emulator (swtpm) could still adjust this size
of the buffer to within bounds supported by swtpm+libtpms if the chosen
size was outside the acceptable range. This could theoretically lead to
the TPM 2 using a bigger buffer than what was requested and memory
allocated for. In practice this would not happend since the requested size
of 4096 bytes for TIS and SPAPR and 3968 bytes for CRB happen in the
(currently) supported range of ~2.5kb to 4096 bytes. With PQC support
the range will have an upper bound of 8kb and a lower bound that will
support the (pre-PQC) CRB with 3968 bytes.
Arun Menon [Wed, 6 May 2026 07:58:13 +0000 (13:28 +0530)]
hw/tpm: Add support for VM migration with TPM CRB chunking
- Add subsection in VMState for TPM CRB with the newly introduced
command and response buffer GByteArrays, along with a needed callback,
so that newer QEMU only sends the buffers if it is necessary.
- Implement a migration blocker to prevent migration of the VM if the
user manually enables chunking capability, cap-chunk, but the machine
type does not support it, using a new hw_compat property called
allow_chunk_migration.
- Add a post_load_errp hook so that during a migration, the buffers are
validated before destination VM is started.
Arun Menon [Wed, 6 May 2026 07:58:12 +0000 (13:28 +0530)]
test/qtest: Add test for tpm crb chunking
- New test case added to the swtpm test. Data is written and read from
the buffer in chunks.
- The chunk size is dynamically calculated by reading the
CRB_CTRL_CMD_SIZE address. This can be changed manually to test.
- Add a helper function tpm_wait_till_bit_clear()
- Note that this commit does not yet exercise the chunked read/write
logic, as current transfer sizes remain small. Testing for large
transfers is introduced in a subsequent patch: 'tests: Use ML-DSA-87
operations to cause large TPM transfers with CRB'
Arun Menon [Wed, 6 May 2026 07:58:11 +0000 (13:28 +0530)]
hw/tpm: Implement TPM CRB chunking logic
- Add logic to populate internal TPM command request and response
buffers and to toggle the control registers after each operation.
- The chunk size is limited to CRB_CTRL_CMD_SIZE which is
(TPM_CRB_ADDR_SIZE - A_CRB_DATA_BUFFER). This comes out as 3968 bytes
(4096 - 128 or 0x1000 - 0x80), because 128 bytes are reserved for
control and status registers. In other words, only 3968 bytes are
available for the TPM data.
- With this feature, guests can send commands larger than 3968 bytes.
- Refer section 6.5.3.9 of [1] for implementation details.
Arun Menon [Wed, 6 May 2026 07:58:08 +0000 (13:28 +0530)]
hw/tpm: Add TPM CRB chunking fields
- Add new fields to the CRB Interface Identifier and the CRB
Control Start registers.
- CRB_CTRL_START now has 2 new settings, that can be toggled using the
nextChunk and crbRspRetry bits.
- CapCRBChunk bit (10) was Reserved1 previously. The field is reused in
this revision of the specification. Refer to section 6.4.2.2 of [1]
- Add hw_compat global property called cap-chunk because the chunking
feature is only supported for machine type 11.1 and higher.
ui/vdagent: Use VMSTATE_GBYTEARRAY to safely migrate outbuf
Migrating a GLib GByteArray is now possible directly using the newly
introduced VMSTATE_GBYTEARRAY. It uses the standard GLib API calls to
create the array, or resize it.
This is safer than implementing a C struct and manually updating the
data and len fields. This commit uses the VMSTATE_GBYTEARRAY in vdagent
to store the outbuf variable.
migration/vmstate: Add VMState support for GByteArray
In GLib, GByteArray is an object managed by the library. Currently,
migrating a GByteArray requires treating it as a raw C struct and using
VMSTATE_VBUFFER_ALLOC_UINT32. For example, see vmstate_vdba in
ui/vdagent.c
QEMU cannot pretend that GByteArray is a C struct and simply use
VMS_ALLOC to g_malloc() the buffer. This is because, VMS_ALLOC blindly
overwrites the data pointer with a newly allocated buffer, thereby
leaking the previous memory. Besides, GLib tracks the array's capacity
in a hidden alloc field. Bypassing GLib APIs leave this capacity out of
sync with the newly allocated buffer, potentially leading to heap buffer
overflows during subsequent g_byte_array_append() calls.
This commit introduces VMSTATE_GBYTEARRAY which uses specific library
API calls (g_byte_array_set_size()) to safely resize and populate the
buffer.
Alex Bennée [Mon, 1 Jun 2026 14:31:29 +0000 (15:31 +0100)]
configure: use debian-all-test-cross for mipsel tcg tests
Although we have had the mips compilers in all-test-cross for a while
we had been surviving using the mipsel cross compiler image. However
when that was removed we missed updating the container to use.
Fixes: 366bb88e785 (buildsys: Remove MIPS cross containers) Reviewed-by: Philippe Mathieu-Daudé <philmd@linaro.org> Reviewed-by: Pierrick Bouvier <pierrick.bouvier@oss.qualcomm.com> Tested-by: Cornelia Huck <cohuck@redhat.com> # running tests on an s390x
Message-ID: <20260601143129.144786-4-alex.bennee@linaro.org> Signed-off-by: Alex Bennée <alex.bennee@linaro.org>
Alex Bennée [Mon, 1 Jun 2026 14:31:28 +0000 (15:31 +0100)]
gitlab: work around the inability to build targets for MacOS
Unfortunately a previous fix to ensure .ninja-goals was set for the
TCG tests broken the ability to run check-functional-FOO. As we have
now reverted we need a solution for the MacOS gitlab run. The simplest
is to add an explicit make invocation to build the signed binaries
before we run the tests.
Reviewed-by: Pierrick Bouvier <pierrick.bouvier@oss.qualcomm.com> Tested-by: Cornelia Huck <cohuck@redhat.com> # running tests on an s390x
Message-ID: <20260601143129.144786-3-alex.bennee@linaro.org> Signed-off-by: Alex Bennée <alex.bennee@linaro.org>
* tag 'pull-9p-20260601' of https://github.com/cschoenebeck/qemu:
9pfs: fix missing rename lock in v9fs_co_readdir_many (CVE-2026-48004)
tests/9pfs: add deep absolute path test
tests/qtest/libqos: add qvirtqueue_reset_pool() for descriptor pool reset
hw/9pfs: let callers of v9fs_path_sprintf() and v9fs_fix_path() handle errors
hw/9pfs: add error handling to v9fs_fix_path()
hw/9pfs: change V9fsPath.size to size_t and v9fs_path_sprintf() return type
hw/9pfs: add NULL check in v9fs_path_is_ancestor()
Signed-off-by: Stefan Hajnoczi <stefanha@redhat.com>
# -----BEGIN PGP SIGNATURE-----
#
# iLMEAAEKAB0WIQTKRzxE1qCcGJoZP81FK5aFKyaCFgUCah0tmwAKCRBFK5aFKyaC
# Fht2BACdtjM7Kod8mgVJVOsJ5M9jRR4DiOfHuo60MNlQ4xE8oYk/g50FMrquoGFt
# lq7KsiWV2CAv0ERi2KDtOtZdfUODdmgI2qOsXEtTwkGIe1Kx4NqEqwAasiiQMTcz
# WwAd9mCsK+Cezs4TJUzeir4xoek/T6mSITUTmjHKUoVe81ZDEQ==
# =Mq/l
# -----END PGP SIGNATURE-----
# gpg: Signature made Mon 01 Jun 2026 02:58:35 EDT
# gpg: using RSA key CA473C44D6A09C189A193FCD452B96852B268216
# gpg: Good signature from "Song Gao <gaosong@loongson.cn>" [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: CA47 3C44 D6A0 9C18 9A19 3FCD 452B 9685 2B26 8216
* tag 'pull-loongarch-20260601' of https://github.com/gaosong715/qemu:
target/loongarch/kvm: Include missing exec/target_long.h header
Signed-off-by: Stefan Hajnoczi <stefanha@redhat.com>
Stefan Hajnoczi [Mon, 1 Jun 2026 12:43:24 +0000 (08:43 -0400)]
Merge tag 'pull-hex-20260529' of https://github.com/qualcomm/qemu into staging
Hexagon cross-toolchain container update
# -----BEGIN PGP SIGNATURE-----
#
# iQIzBAABCgAdFiEEPWaq5HRZSCTIjOD4GlSvuOVkbDIFAmoaJP8ACgkQGlSvuOVk
# bDKJ2g/+MTJnhD/YLM7q6sYpRuQJv0kJd3cIuQ1HbFskJo2sJFPdNLTAhWmfggST
# J8OvnQwsWg3QCLQ92YaYZ/jYSVsmF3S8cbQW4fKG18FgCRQkARGmOZmoQM+POCvP
# Tjfw9m8d4uQUCUV8yByK0nosY+0Iy+rXHVoJMBsKeRK1zLtKKLPe1hRkcpN7anaB
# Nskce1nKmI6T/CU1RPPPBDJkzse/+l4BUTmnVIu6Brir3f2/6TbAIceP9pybYjDw
# i+LchG04MWVXZcfe4D0/ihazDWoy8xWjBixLON+aw9zSjLGznRHj8IEZojmW018G
# 2ifqUHkRPw6LBtUf1JGs+2ldonwRaerE4ik2yc48N73oOn5nNNcV5/kVdMsxfRYS
# O/FCihJzNoZQJ64KvL5vVxrx6x4kgI3bZi1k5sIYAKzSg6LUfxE6NW3bUVihrO5a
# s9qV+cofc03Sv1a7A4jrUvdvwQILblUTB2GQrYnREioVEm/X4eK4I5xUaqd1p00t
# IH9VpzDX+O2q72HjQ224OnTnPsUkuHiOfZj+X2Zqy1647WwGd+DYjbu9P8ht78W2
# klWPhD0gsEluZu/PV4AdxjajH1V/KtMIDZcYZWjclf1/M0RV1Y2OLGeDIjld7PQi
# HdSBRrKQanyQu97/qa3TEKo6ot1aIiI13SX24cpOx70hspcyIJo=
# =/CUP
# -----END PGP SIGNATURE-----
# gpg: Signature made Fri 29 May 2026 19:45:03 EDT
# gpg: using RSA key 3D66AAE474594824C88CE0F81A54AFB8E5646C32
# gpg: Good signature from "Brian Cain (OSS Qualcomm) <brian.cain@oss.qualcomm.com>" [unknown]
# gpg: aka "Brian Cain <bcain@kernel.org>" [unknown]
# gpg: aka "Brian Cain (QuIC) <bcain@quicinc.com>" [unknown]
# gpg: aka "Brian Cain (CAF) <bcain@codeaurora.org>" [unknown]
# gpg: aka "bcain" [unknown]
# gpg: aka "Brian Cain (QUIC) <quic_bcain@quicinc.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: 6350 20F9 67A7 7164 79EF 49E0 175C 464E 541B 6D47
# Subkey fingerprint: 3D66 AAE4 7459 4824 C88C E0F8 1A54 AFB8 E564 6C32
* tag 'pull-hex-20260529' of https://github.com/qualcomm/qemu:
tests/docker: Update hexagon cross toolchain to 22.1.0
tests/tcg/hexagon: fix check_rev_gating with newer toolchain
Signed-off-by: Stefan Hajnoczi <stefanha@redhat.com>
Stefan Hajnoczi [Mon, 1 Jun 2026 12:43:12 +0000 (08:43 -0400)]
Merge tag 'linux-user-next-pull-request' of https://github.com/hdeller/qemu-hppa into staging
linux user patches
A series of patches for linux-user, specifically many FPU fixes in signal
handling code for sh4, mips, ppc and s390x (from Matt Turner), a madvise()
improvement (from me), and qemu header cleanups (from Peter Maydell).
---
v3: Fix build failure due to unknown MADV_COLLAPSE constant in madivise() patch
v2: Dropped the "ARM cortex-m55 program loading fix" and the FPU alpha patch
# -----BEGIN PGP SIGNATURE-----
#
# iHUEABYKAB0WIQS86RI+GtKfB8BJu973ErUQojoPXwUCahoKTQAKCRD3ErUQojoP
# XxTMAPwP1hvkA5oV+NCS4y15eTTwycxsEKiSBV0cysz6pkgVGgEA3njxgnnH9iqM
# AxeLtQWJAb3WHNyfDpnj+RLo/xUehQY=
# =jFvz
# -----END PGP SIGNATURE-----
# gpg: Signature made Fri 29 May 2026 17:51:09 EDT
# gpg: using EDDSA key BCE9123E1AD29F07C049BBDEF712B510A23A0F5F
# gpg: Good signature from "Helge Deller <deller@gmx.de>" [unknown]
# gpg: aka "Helge Deller <deller@kernel.org>" [unknown]
# gpg: aka "Helge Deller <deller@debian.org>" [unknown]
# gpg: WARNING: This key is not certified with a trusted signature!
# gpg: There is no indication that the signature belongs to the owner.
# Primary key fingerprint: 4544 8228 2CD9 10DB EF3D 25F8 3E5F 3D04 A7A2 4603
# Subkey fingerprint: BCE9 123E 1AD2 9F07 C049 BBDE F712 B510 A23A 0F5F
* tag 'linux-user-next-pull-request' of https://github.com/hdeller/qemu-hppa:
linux-user: Move cpu_copy() to user-internals.h
linux-user: Move init_main_thread() prototype to user-internals.h
linux-user: Fix typo in function documentation for pgb_addr_set()
linux-user: Implement finer grained madivse() syscall
linux-user/s390x: restore fpu_status rounding mode from FPC on sigreturn
target/sh4: sync fp_status when gdb writes FPSCR
linux-user/sh4: restore FP rounding mode on sigreturn
linux-user/sh4: preserve T/M/Q bits across signal delivery
linux-user/mips: save/restore FCSR across signal delivery
linux-user/ppc: restore fp_status from FPSCR on sigreturn
Signed-off-by: Stefan Hajnoczi <stefanha@redhat.com>
* tag 'pull-tcg-20260529' of https://gitlab.com/rth7680/qemu:
tcg: Optimize INDEX_op_mul[us]2 for 0 and 1
tcg: Massage fold_multiply2()
docs/devel/tcg-ops: Fix reStructuredText format
Signed-off-by: Stefan Hajnoczi <stefanha@redhat.com>
projects / thirdparty / qemu.git / log
