Branch: refs/heads/master
Home: https://github.com/qemu/qemu
Commit: 573581b18dfd458ddac22f832bfb3f6fc9b585dc
https://github.com/qemu/qemu/commit/573581b18dfd458ddac22f832bfb3f6fc9b585dc
Author: Si-Wei Liu <si-wei....@oracle.com>
Date: 2024-03-12 (Tue, 12 Mar 2024)
Changed paths:
M net/vhost-vdpa.c
Log Message:
-----------
vdpa: add back vhost_vdpa_net_first_nc_vdpa
Previous commits had it removed. Now adding it back because
this function will be needed by future patches.
Message-Id: <1707910082-10243-2-git-send-email-si-wei....@oracle.com>
Reviewed-by: Eugenio Pérez <epere...@redhat.com>
Signed-off-by: Si-Wei Liu <si-wei....@oracle.com>
Reviewed-by: Michael S. Tsirkin <m...@redhat.com>
Signed-off-by: Michael S. Tsirkin <m...@redhat.com>
Commit: c812b0655f8ccd1def48f14b89cec07e8fb68d83
https://github.com/qemu/qemu/commit/c812b0655f8ccd1def48f14b89cec07e8fb68d83
Author: Si-Wei Liu <si-wei....@oracle.com>
Date: 2024-03-12 (Tue, 12 Mar 2024)
Changed paths:
M hw/virtio/vhost-vdpa.c
Log Message:
-----------
vdpa: factor out vhost_vdpa_last_dev
Generalize duplicated condition check for the last vq of vdpa
device to a common function.
Message-Id: <1707910082-10243-4-git-send-email-si-wei....@oracle.com>
Reviewed-by: Eugenio Pérez <epere...@redhat.com>
Acked-by: Jason Wang <jasow...@redhat.com>
Signed-off-by: Si-Wei Liu <si-wei....@oracle.com>
Reviewed-by: Michael S. Tsirkin <m...@redhat.com>
Signed-off-by: Michael S. Tsirkin <m...@redhat.com>
Commit: 77c3a336a44272e8a6e9b18c6b765f08aa84151f
https://github.com/qemu/qemu/commit/77c3a336a44272e8a6e9b18c6b765f08aa84151f
Author: Si-Wei Liu <si-wei....@oracle.com>
Date: 2024-03-12 (Tue, 12 Mar 2024)
Changed paths:
M net/vhost-vdpa.c
Log Message:
-----------
vdpa: factor out vhost_vdpa_net_get_nc_vdpa
Introduce new API. No functional change on existing API.
Message-Id: <1707910082-10243-5-git-send-email-si-wei....@oracle.com>
Reviewed-by: Eugenio Pérez <epere...@redhat.com>
Acked-by: Jason Wang <jasow...@redhat.com>
Signed-off-by: Si-Wei Liu <si-wei....@oracle.com>
Reviewed-by: Michael S. Tsirkin <m...@redhat.com>
Signed-off-by: Michael S. Tsirkin <m...@redhat.com>
Commit: 62845d3296ab7565e66f6e1f7bcfedb877f6fe7b
https://github.com/qemu/qemu/commit/62845d3296ab7565e66f6e1f7bcfedb877f6fe7b
Author: Si-Wei Liu <si-wei....@oracle.com>
Date: 2024-03-12 (Tue, 12 Mar 2024)
Changed paths:
M net/trace-events
M net/vhost-vdpa.c
Log Message:
-----------
vdpa: add vhost_vdpa_set_address_space_id trace
For better debuggability and observability.
Message-Id: <1707910082-10243-6-git-send-email-si-wei....@oracle.com>
Reviewed-by: Eugenio Pérez <epere...@redhat.com>
Signed-off-by: Si-Wei Liu <si-wei....@oracle.com>
Reviewed-by: Michael S. Tsirkin <m...@redhat.com>
Signed-off-by: Michael S. Tsirkin <m...@redhat.com>
Commit: 6ec0a7467828f228e00ec83978fb5267f81079e0
https://github.com/qemu/qemu/commit/6ec0a7467828f228e00ec83978fb5267f81079e0
Author: Si-Wei Liu <si-wei....@oracle.com>
Date: 2024-03-12 (Tue, 12 Mar 2024)
Changed paths:
M hw/virtio/trace-events
M hw/virtio/vhost-vdpa.c
Log Message:
-----------
vdpa: add vhost_vdpa_get_vring_base trace for svq mode
For better debuggability and observability.
Message-Id: <1707910082-10243-7-git-send-email-si-wei....@oracle.com>
Reviewed-by: Eugenio Pérez <epere...@redhat.com>
Acked-by: Jason Wang <jasow...@redhat.com>
Signed-off-by: Si-Wei Liu <si-wei....@oracle.com>
Reviewed-by: Michael S. Tsirkin <m...@redhat.com>
Signed-off-by: Michael S. Tsirkin <m...@redhat.com>
Commit: 19a060bce17316d9ff7d8b3637fb391010be8144
https://github.com/qemu/qemu/commit/19a060bce17316d9ff7d8b3637fb391010be8144
Author: Si-Wei Liu <si-wei....@oracle.com>
Date: 2024-03-12 (Tue, 12 Mar 2024)
Changed paths:
M hw/virtio/trace-events
M hw/virtio/vhost-vdpa.c
Log Message:
-----------
vdpa: add vhost_vdpa_set_dev_vring_base trace for svq mode
For better debuggability and observability.
Message-Id: <1707910082-10243-8-git-send-email-si-wei....@oracle.com>
Reviewed-by: Eugenio Pérez <epere...@redhat.com>
Acked-by: Jason Wang <jasow...@redhat.com>
Signed-off-by: Si-Wei Liu <si-wei....@oracle.com>
Reviewed-by: Michael S. Tsirkin <m...@redhat.com>
Signed-off-by: Michael S. Tsirkin <m...@redhat.com>
Commit: faed74468fe4ade9503025094f8a03673c8bd416
https://github.com/qemu/qemu/commit/faed74468fe4ade9503025094f8a03673c8bd416
Author: Si-Wei Liu <si-wei....@oracle.com>
Date: 2024-03-12 (Tue, 12 Mar 2024)
Changed paths:
M net/trace-events
M net/vhost-vdpa.c
Log Message:
-----------
vdpa: add trace events for vhost_vdpa_net_load_cmd
For better debuggability and observability.
Message-Id: <1707910082-10243-9-git-send-email-si-wei....@oracle.com>
Reviewed-by: Eugenio Pérez <epere...@redhat.com>
Signed-off-by: Si-Wei Liu <si-wei....@oracle.com>
Reviewed-by: Michael S. Tsirkin <m...@redhat.com>
Signed-off-by: Michael S. Tsirkin <m...@redhat.com>
Commit: 1c4eab477fb0aa5a039513c26dac63d3460e1b08
https://github.com/qemu/qemu/commit/1c4eab477fb0aa5a039513c26dac63d3460e1b08
Author: Si-Wei Liu <si-wei....@oracle.com>
Date: 2024-03-12 (Tue, 12 Mar 2024)
Changed paths:
M net/trace-events
M net/vhost-vdpa.c
Log Message:
-----------
vdpa: add trace event for vhost_vdpa_net_load_mq
For better debuggability and observability.
Message-Id: <1707910082-10243-10-git-send-email-si-wei....@oracle.com>
Reviewed-by: Eugenio Pérez <epere...@redhat.com>
Signed-off-by: Si-Wei Liu <si-wei....@oracle.com>
Reviewed-by: Michael S. Tsirkin <m...@redhat.com>
Signed-off-by: Michael S. Tsirkin <m...@redhat.com>
Commit: bb000fff0a1d9774444c431e0831550e99e159ce
https://github.com/qemu/qemu/commit/bb000fff0a1d9774444c431e0831550e99e159ce
Author: Si-Wei Liu <si-wei....@oracle.com>
Date: 2024-03-12 (Tue, 12 Mar 2024)
Changed paths:
M include/hw/virtio/vhost-vdpa.h
Log Message:
-----------
vdpa: define SVQ transitioning state for mode switching
Will be used in following patches.
DISABLING(-1) means SVQ is being switched off to passthrough
mode.
ENABLING(1) means passthrough VQs are being switched to SVQ.
DONE(0) means SVQ switching is completed.
Message-Id: <1707910082-10243-11-git-send-email-si-wei....@oracle.com>
Signed-off-by: Si-Wei Liu <si-wei....@oracle.com>
Reviewed-by: Michael S. Tsirkin <m...@redhat.com>
Signed-off-by: Michael S. Tsirkin <m...@redhat.com>
Commit: db4cba36a7356f5e94e97735af8c578c55838386
https://github.com/qemu/qemu/commit/db4cba36a7356f5e94e97735af8c578c55838386
Author: Si-Wei Liu <si-wei....@oracle.com>
Date: 2024-03-12 (Tue, 12 Mar 2024)
Changed paths:
M net/vhost-vdpa.c
Log Message:
-----------
vdpa: indicate transitional state for SVQ switching
svq_switching indicates the transitional state whether
or not SVQ mode switching is in progress, and towards
which direction. Add the neccessary state around where
the switching would take place.
Message-Id: <1707910082-10243-12-git-send-email-si-wei....@oracle.com>
Signed-off-by: Si-Wei Liu <si-wei....@oracle.com>
Reviewed-by: Michael S. Tsirkin <m...@redhat.com>
Signed-off-by: Michael S. Tsirkin <m...@redhat.com>
Commit: 9ed62809b6e28ab0d887aff502ed24f77f1edafd
https://github.com/qemu/qemu/commit/9ed62809b6e28ab0d887aff502ed24f77f1edafd
Author: Si-Wei Liu <si-wei....@oracle.com>
Date: 2024-03-12 (Tue, 12 Mar 2024)
Changed paths:
M hw/virtio/vhost-vdpa.c
Log Message:
-----------
vdpa: fix network breakage after cancelling migration
Fix an issue where cancellation of ongoing migration ends up
with no network connectivity.
When canceling migration, SVQ will be switched back to the
passthrough mode, but the right call fd is not programed to
the device and the svq's own call fd is still used. At the
point of this transitioning period, the shadow_vqs_enabled
hadn't been set back to false yet, causing the installation
of call fd inadvertently bypassed.
Message-Id: <1707910082-10243-13-git-send-email-si-wei....@oracle.com>
Fixes: a8ac88585da1 ("vhost: Add Shadow VirtQueue call forwarding capabilities")
Cc: Eugenio Pérez <epere...@redhat.com>
Acked-by: Jason Wang <jasow...@redhat.com>
Signed-off-by: Si-Wei Liu <si-wei....@oracle.com>
Reviewed-by: Michael S. Tsirkin <m...@redhat.com>
Signed-off-by: Michael S. Tsirkin <m...@redhat.com>
Commit: d884e2727849fc95d337262ec91be60165473c4a
https://github.com/qemu/qemu/commit/d884e2727849fc95d337262ec91be60165473c4a
Author: David Hildenbrand <da...@redhat.com>
Date: 2024-03-12 (Tue, 12 Mar 2024)
Changed paths:
M subprojects/libvhost-user/libvhost-user.c
M subprojects/libvhost-user/libvhost-user.h
Log Message:
-----------
libvhost-user: Dynamically allocate memory for memory slots
Let's prepare for increasing VHOST_USER_MAX_RAM_SLOTS by dynamically
allocating dev->regions. We don't have any ABI guarantees (not
dynamically linked), so we can simply change the layout of VuDev.
Let's zero out the memory, just as we used to do.
Reviewed-by: Raphael Norwitz <raph...@enfabrica.net>
Acked-by: Stefano Garzarella <sgarz...@redhat.com>
Signed-off-by: David Hildenbrand <da...@redhat.com>
Message-Id: <20240214151701.29906-2-da...@redhat.com>
Tested-by: Mario Casquero <mcasq...@redhat.com>
Reviewed-by: Michael S. Tsirkin <m...@redhat.com>
Signed-off-by: Michael S. Tsirkin <m...@redhat.com>
Commit: 0fa6344c90a093e2421ecac3c96a8823ad74ee89
https://github.com/qemu/qemu/commit/0fa6344c90a093e2421ecac3c96a8823ad74ee89
Author: David Hildenbrand <da...@redhat.com>
Date: 2024-03-12 (Tue, 12 Mar 2024)
Changed paths:
M subprojects/libvhost-user/libvhost-user.h
Log Message:
-----------
libvhost-user: Bump up VHOST_USER_MAX_RAM_SLOTS to 509
Let's support up to 509 mem slots, just like vhost in the kernel usually
does and the rust vhost-user implementation recently [1] started doing.
This is required to properly support memory hotplug, either using
multiple DIMMs (ACPI supports up to 256) or using virtio-mem.
The 509 used to be the KVM limit, it supported 512, but 3 were
used for internal purposes. Currently, KVM supports more than 512, but
it usually doesn't make use of more than ~260 (i.e., 256 DIMMs + boot
memory), except when other memory devices like PCI devices with BARs are
used. So, 509 seems to work well for vhost in the kernel.
Details can be found in the QEMU change that made virtio-mem consume
up to 256 mem slots across all virtio-mem devices. [2]
509 mem slots implies 509 VMAs/mappings in the worst case (even though,
in practice with virtio-mem we won't be seeing more than ~260 in most
setups).
With max_map_count under Linux defaulting to 64k, 509 mem slots
still correspond to less than 1% of the maximum number of mappings.
There are plenty left for the application to consume.
[1] https://github.com/rust-vmm/vhost/pull/224
[2] https://lore.kernel.org/all/20230926185738.277351-1-da...@redhat.com/
Reviewed-by: Raphael Norwitz <raph...@enfabrica.net>
Acked-by: Stefano Garzarella <sgarz...@redhat.com>
Signed-off-by: David Hildenbrand <da...@redhat.com>
Message-Id: <20240214151701.29906-3-da...@redhat.com>
Tested-by: Mario Casquero <mcasq...@redhat.com>
Reviewed-by: Michael S. Tsirkin <m...@redhat.com>
Signed-off-by: Michael S. Tsirkin <m...@redhat.com>
Commit: bec5820908919f70f87b57b92e4c92be128f5cfd
https://github.com/qemu/qemu/commit/bec5820908919f70f87b57b92e4c92be128f5cfd
Author: David Hildenbrand <da...@redhat.com>
Date: 2024-03-12 (Tue, 12 Mar 2024)
Changed paths:
M subprojects/libvhost-user/libvhost-user.c
Log Message:
-----------
libvhost-user: Factor out removing all mem regions
Let's factor it out. Note that the check for MAP_FAILED was wrong as
we never set mmap_addr if mmap() failed. We'll remove the NULL check
separately.
Reviewed-by: Raphael Norwitz <raph...@enfabrica.net>
Acked-by: Stefano Garzarella <sgarz...@redhat.com>
Signed-off-by: David Hildenbrand <da...@redhat.com>
Message-Id: <20240214151701.29906-4-da...@redhat.com>
Tested-by: Mario Casquero <mcasq...@redhat.com>
Reviewed-by: Michael S. Tsirkin <m...@redhat.com>
Signed-off-by: Michael S. Tsirkin <m...@redhat.com>
Commit: 05a58ce47167a95b554f9afc47f78f267c394c6e
https://github.com/qemu/qemu/commit/05a58ce47167a95b554f9afc47f78f267c394c6e
Author: David Hildenbrand <da...@redhat.com>
Date: 2024-03-12 (Tue, 12 Mar 2024)
Changed paths:
M subprojects/libvhost-user/libvhost-user.c
Log Message:
-----------
libvhost-user: Merge vu_set_mem_table_exec_postcopy() into
vu_set_mem_table_exec()
Let's reduce some code duplication and prepare for further changes.
Reviewed-by: Raphael Norwitz <raph...@enfabrica.net>
Acked-by: Stefano Garzarella <sgarz...@redhat.com>
Signed-off-by: David Hildenbrand <da...@redhat.com>
Message-Id: <20240214151701.29906-5-da...@redhat.com>
Tested-by: Mario Casquero <mcasq...@redhat.com>
Reviewed-by: Michael S. Tsirkin <m...@redhat.com>
Signed-off-by: Michael S. Tsirkin <m...@redhat.com>
Commit: 93fec23d8cecebf0e6917044a0c1635df20e350d
https://github.com/qemu/qemu/commit/93fec23d8cecebf0e6917044a0c1635df20e350d
Author: David Hildenbrand <da...@redhat.com>
Date: 2024-03-12 (Tue, 12 Mar 2024)
Changed paths:
M subprojects/libvhost-user/libvhost-user.c
Log Message:
-----------
libvhost-user: Factor out adding a memory region
Let's factor it out, reducing quite some code duplication and perparing
for further changes.
If we fail to mmap a region and panic, we now simply don't add that
(broken) region.
Note that we now increment dev->nregions as we are successfully
adding memory regions, and don't increment dev->nregions if anything went
wrong.
Reviewed-by: Raphael Norwitz <raph...@enfabrica.net>
Acked-by: Stefano Garzarella <sgarz...@redhat.com>
Signed-off-by: David Hildenbrand <da...@redhat.com>
Message-Id: <20240214151701.29906-6-da...@redhat.com>
Tested-by: Mario Casquero <mcasq...@redhat.com>
Reviewed-by: Michael S. Tsirkin <m...@redhat.com>
Signed-off-by: Michael S. Tsirkin <m...@redhat.com>
Commit: 4f865c3b15a71dbeae999a10256742751410394e
https://github.com/qemu/qemu/commit/4f865c3b15a71dbeae999a10256742751410394e
Author: David Hildenbrand <da...@redhat.com>
Date: 2024-03-12 (Tue, 12 Mar 2024)
Changed paths:
M subprojects/libvhost-user/libvhost-user.c
Log Message:
-----------
libvhost-user: No need to check for NULL when unmapping
We never add a memory region if mmap() failed. Therefore, no need to check
for NULL.
Reviewed-by: Raphael Norwitz <raph...@enfabrica.net>
Acked-by: Stefano Garzarella <sgarz...@redhat.com>
Signed-off-by: David Hildenbrand <da...@redhat.com>
Message-Id: <20240214151701.29906-7-da...@redhat.com>
Tested-by: Mario Casquero <mcasq...@redhat.com>
Reviewed-by: Michael S. Tsirkin <m...@redhat.com>
Signed-off-by: Michael S. Tsirkin <m...@redhat.com>
Commit: c6f90b785291389168b15fe797788bcbb5a7803a
https://github.com/qemu/qemu/commit/c6f90b785291389168b15fe797788bcbb5a7803a
Author: David Hildenbrand <da...@redhat.com>
Date: 2024-03-12 (Tue, 12 Mar 2024)
Changed paths:
M subprojects/libvhost-user/libvhost-user.c
Log Message:
-----------
libvhost-user: Don't zero out memory for memory regions
dev->nregions always covers only valid entries. Stop zeroing out other
array elements that are unused.
Reviewed-by: Raphael Norwitz <raph...@enfabrica.net>
Acked-by: Stefano Garzarella <sgarz...@redhat.com>
Signed-off-by: David Hildenbrand <da...@redhat.com>
Message-Id: <20240214151701.29906-8-da...@redhat.com>
Tested-by: Mario Casquero <mcasq...@redhat.com>
Reviewed-by: Michael S. Tsirkin <m...@redhat.com>
Signed-off-by: Michael S. Tsirkin <m...@redhat.com>
Commit: 9c254cb413a631f6601e6e34429547759d7d63a6
https://github.com/qemu/qemu/commit/9c254cb413a631f6601e6e34429547759d7d63a6
Author: David Hildenbrand <da...@redhat.com>
Date: 2024-03-12 (Tue, 12 Mar 2024)
Changed paths:
M subprojects/libvhost-user/libvhost-user.c
Log Message:
-----------
libvhost-user: Don't search for duplicates when removing memory regions
We cannot have duplicate memory regions, something would be deeply
flawed elsewhere. Let's just stop the search once we found an entry.
We'll add more sanity checks when adding memory regions later.
Reviewed-by: Raphael Norwitz <raph...@enfabrica.net>
Acked-by: Stefano Garzarella <sgarz...@redhat.com>
Signed-off-by: David Hildenbrand <da...@redhat.com>
Message-Id: <20240214151701.29906-9-da...@redhat.com>
Tested-by: Mario Casquero <mcasq...@redhat.com>
Reviewed-by: Michael S. Tsirkin <m...@redhat.com>
Signed-off-by: Michael S. Tsirkin <m...@redhat.com>
Commit: 60ccdca42d96f730f57478caaf376da90c3d97f3
https://github.com/qemu/qemu/commit/60ccdca42d96f730f57478caaf376da90c3d97f3
Author: David Hildenbrand <da...@redhat.com>
Date: 2024-03-12 (Tue, 12 Mar 2024)
Changed paths:
M subprojects/libvhost-user/libvhost-user.c
Log Message:
-----------
libvhost-user: Factor out search for memory region by GPA and simplify
Memory regions cannot overlap, and if we ever hit that case something
would be really flawed.
For example, when vhost code in QEMU decides to increase the size of memory
regions to cover full huge pages, it makes sure to never create overlaps,
and if there would be overlaps, it would bail out.
QEMU commits 48d7c9757749 ("vhost: Merge sections added to temporary
list"), c1ece84e7c93 ("vhost: Huge page align and merge") and
e7b94a84b6cb ("vhost: Allow adjoining regions") added and clarified that
handling and how overlaps are impossible.
Consequently, each GPA can belong to at most one memory region, and
everything else doesn't make sense. Let's factor out our search to prepare
for further changes.
Reviewed-by: Raphael Norwitz <raph...@enfabrica.net>
Acked-by: Stefano Garzarella <sgarz...@redhat.com>
Signed-off-by: David Hildenbrand <da...@redhat.com>
Message-Id: <20240214151701.29906-10-da...@redhat.com>
Tested-by: Mario Casquero <mcasq...@redhat.com>
Reviewed-by: Michael S. Tsirkin <m...@redhat.com>
Signed-off-by: Michael S. Tsirkin <m...@redhat.com>
Commit: a3c0118c5a1e64d32a2208388b5ea90e2ec9d214
https://github.com/qemu/qemu/commit/a3c0118c5a1e64d32a2208388b5ea90e2ec9d214
Author: David Hildenbrand <da...@redhat.com>
Date: 2024-03-12 (Tue, 12 Mar 2024)
Changed paths:
M subprojects/libvhost-user/libvhost-user.c
Log Message:
-----------
libvhost-user: Speedup gpa_to_mem_region() and vu_gpa_to_va()
Let's speed up GPA to memory region / virtual address lookup. Store the
memory regions ordered by guest physical addresses, and use binary
search for address translation, as well as when adding/removing memory
regions.
Most importantly, this will speed up GPA->VA address translation when we
have many memslots.
Reviewed-by: Raphael Norwitz <raph...@enfabrica.net>
Acked-by: Stefano Garzarella <sgarz...@redhat.com>
Signed-off-by: David Hildenbrand <da...@redhat.com>
Message-Id: <20240214151701.29906-11-da...@redhat.com>
Tested-by: Mario Casquero <mcasq...@redhat.com>
Reviewed-by: Michael S. Tsirkin <m...@redhat.com>
Signed-off-by: Michael S. Tsirkin <m...@redhat.com>
Commit: b2b63008b311126ade0a44ddb488d3704dffa51f
https://github.com/qemu/qemu/commit/b2b63008b311126ade0a44ddb488d3704dffa51f
Author: David Hildenbrand <da...@redhat.com>
Date: 2024-03-12 (Tue, 12 Mar 2024)
Changed paths:
M subprojects/libvhost-user/libvhost-user.c
Log Message:
-----------
libvhost-user: Use most of mmap_offset as fd_offset
In the past, QEMU would create memory regions that could partially cover
hugetlb pages, making mmap() fail if we would use the mmap_offset as an
fd_offset. For that reason, we never used the mmap_offset as an offset into
the fd and instead always mapped the fd from the very start.
However, that can easily result in us mmap'ing a lot of unnecessary
parts of an fd, possibly repeatedly.
QEMU nowadays does not create memory regions that partially cover huge
pages -- it never really worked with postcopy. QEMU handles merging of
regions that partially cover huge pages (due to holes in boot memory) since
2018 in c1ece84e7c93 ("vhost: Huge page align and merge").
Let's be a bit careful and not unconditionally convert the
mmap_offset into an fd_offset. Instead, let's simply detect the hugetlb
size and pass as much as we can as fd_offset, making sure that we call
mmap() with a properly aligned offset.
With QEMU and a virtio-mem device that is fully plugged (50GiB using 50
memslots) the qemu-storage daemon process consumes in the VA space
1281GiB before this change and 58GiB after this change.
================ Vhost user message ================
Request: VHOST_USER_ADD_MEM_REG (37)
Flags: 0x9
Size: 40
Fds: 59
Adding region 4
guest_phys_addr: 0x0000000200000000
memory_size: 0x0000000040000000
userspace_addr: 0x00007fb73bffe000
old mmap_offset: 0x0000000080000000
fd_offset: 0x0000000080000000
new mmap_offset: 0x0000000000000000
mmap_addr: 0x00007f02f1bdc000
Successfully added new region
================ Vhost user message ================
Request: VHOST_USER_ADD_MEM_REG (37)
Flags: 0x9
Size: 40
Fds: 59
Adding region 5
guest_phys_addr: 0x0000000240000000
memory_size: 0x0000000040000000
userspace_addr: 0x00007fb77bffe000
old mmap_offset: 0x00000000c0000000
fd_offset: 0x00000000c0000000
new mmap_offset: 0x0000000000000000
mmap_addr: 0x00007f0284000000
Successfully added new region
Reviewed-by: Raphael Norwitz <raph...@enfabrica.net>
Acked-by: Stefano Garzarella <sgarz...@redhat.com>
Signed-off-by: David Hildenbrand <da...@redhat.com>
Message-Id: <20240214151701.29906-12-da...@redhat.com>
Tested-by: Mario Casquero <mcasq...@redhat.com>
Reviewed-by: Michael S. Tsirkin <m...@redhat.com>
Signed-off-by: Michael S. Tsirkin <m...@redhat.com>
Commit: 2a29022768f1777d71e26b784a264323d1914dd6
https://github.com/qemu/qemu/commit/2a29022768f1777d71e26b784a264323d1914dd6
Author: David Hildenbrand <da...@redhat.com>
Date: 2024-03-12 (Tue, 12 Mar 2024)
Changed paths:
M subprojects/libvhost-user/libvhost-user.c
Log Message:
-----------
libvhost-user: Factor out vq usability check
Let's factor it out to prepare for further changes.
Reviewed-by: Raphael Norwitz <raph...@enfabrica.net>
Acked-by: Stefano Garzarella <sgarz...@redhat.com>
Signed-off-by: David Hildenbrand <da...@redhat.com>
Message-Id: <20240214151701.29906-13-da...@redhat.com>
Tested-by: Mario Casquero <mcasq...@redhat.com>
Reviewed-by: Michael S. Tsirkin <m...@redhat.com>
Signed-off-by: Michael S. Tsirkin <m...@redhat.com>
Commit: 67f4f663cd6179d57f3e5a558f1526c7dc8c6742
https://github.com/qemu/qemu/commit/67f4f663cd6179d57f3e5a558f1526c7dc8c6742
Author: David Hildenbrand <da...@redhat.com>
Date: 2024-03-12 (Tue, 12 Mar 2024)
Changed paths:
M subprojects/libvhost-user/libvhost-user.c
Log Message:
-----------
libvhost-user: Dynamically remap rings after (temporarily?) removing memory
regions
Currently, we try to remap all rings whenever we add a single new memory
region. That doesn't quite make sense, because we already map rings when
setting the ring address, and panic if that goes wrong. Likely, that
handling was simply copied from set_mem_table code, where we actually
have to remap all rings.
Remapping all rings might require us to walk quite a lot of memory
regions to perform the address translations. Ideally, we'd simply remove
that remapping.
However, let's be a bit careful. There might be some weird corner cases
where we might temporarily remove a single memory region (e.g., resize
it), that would have worked for now. Further, a ring might be located on
hotplugged memory, and as the VM reboots, we might unplug that memory, to
hotplug memory before resetting the ring addresses.
So let's unmap affected rings as we remove a memory region, and try
dynamically mapping the ring again when required.
Acked-by: Raphael Norwitz <raph...@enfabrica.net>
Acked-by: Stefano Garzarella <sgarz...@redhat.com>
Signed-off-by: David Hildenbrand <da...@redhat.com>
Message-Id: <20240214151701.29906-14-da...@redhat.com>
Tested-by: Mario Casquero <mcasq...@redhat.com>
Reviewed-by: Michael S. Tsirkin <m...@redhat.com>
Signed-off-by: Michael S. Tsirkin <m...@redhat.com>
Commit: 52767e1063beaa17d59c739efd0b9c342923929d
https://github.com/qemu/qemu/commit/52767e1063beaa17d59c739efd0b9c342923929d
Author: David Hildenbrand <da...@redhat.com>
Date: 2024-03-12 (Tue, 12 Mar 2024)
Changed paths:
M subprojects/libvhost-user/libvhost-user.c
Log Message:
-----------
libvhost-user: Mark mmap'ed region memory as MADV_DONTDUMP
We already use MADV_NORESERVE to deal with sparse memory regions. Let's
also set madvise(MADV_DONTDUMP), otherwise a crash of the process can
result in us allocating all memory in the mmap'ed region for dumping
purposes.
This change implies that the mmap'ed rings won't be included in a
coredump. If ever required for debugging purposes, we could mark only
the mapped rings MADV_DODUMP.
Ignore errors during madvise() for now.
Reviewed-by: Raphael Norwitz <raph...@enfabrica.net>
Acked-by: Stefano Garzarella <sgarz...@redhat.com>
Signed-off-by: David Hildenbrand <da...@redhat.com>
Message-Id: <20240214151701.29906-15-da...@redhat.com>
Tested-by: Mario Casquero <mcasq...@redhat.com>
Reviewed-by: Michael S. Tsirkin <m...@redhat.com>
Signed-off-by: Michael S. Tsirkin <m...@redhat.com>
Commit: c08da86dc412cd44039bc78df02227578bc06268
https://github.com/qemu/qemu/commit/c08da86dc412cd44039bc78df02227578bc06268
Author: Lukas Stockner <lstock...@genesiscloud.com>
Date: 2024-03-12 (Tue, 12 Mar 2024)
Changed paths:
M hw/core/qdev-properties-system.c
M hw/pci/pcie.c
M include/hw/pci/pcie_regs.h
M qapi/common.json
Log Message:
-----------
pcie: Support PCIe Gen5/Gen6 link speeds
This patch extends the PCIe link speed option so that slots can be
configured as supporting 32GT/s (Gen5) or 64GT/s (Gen5) speeds.
This is as simple as setting the appropriate bit in LnkCap2 and
the appropriate value in LnkCap and LnkCtl2.
Signed-off-by: Lukas Stockner <lstock...@genesiscloud.com>
Message-Id: <20240215012326.3272366-1-lstock...@genesiscloud.com>
Reviewed-by: Manos Pitsidianakis <manos.pitsidiana...@linaro.org>
Reviewed-by: Michael S. Tsirkin <m...@redhat.com>
Signed-off-by: Michael S. Tsirkin <m...@redhat.com>
Commit: a55834579aa65f27519f948275d5efd9e2173bef
https://github.com/qemu/qemu/commit/a55834579aa65f27519f948275d5efd9e2173bef
Author: Eugenio Pérez <epere...@redhat.com>
Date: 2024-03-12 (Tue, 12 Mar 2024)
Changed paths:
M hw/virtio/vhost-vdpa.c
Log Message:
-----------
vdpa: stash memory region properties in vars
Next changes uses this variables, so avoid call repeatedly to memory
region functions. No functional change intended.
Signed-off-by: Eugenio Pérez <epere...@redhat.com>
Message-Id: <20240215103616.330518-2-epere...@redhat.com>
Reviewed-by: Michael S. Tsirkin <m...@redhat.com>
Signed-off-by: Michael S. Tsirkin <m...@redhat.com>
Commit: a8516e5c9719cf45fd81d6790bc9ffdcf753376b
https://github.com/qemu/qemu/commit/a8516e5c9719cf45fd81d6790bc9ffdcf753376b
Author: Eugenio Pérez <epere...@redhat.com>
Date: 2024-03-12 (Tue, 12 Mar 2024)
Changed paths:
M hw/virtio/trace-events
M hw/virtio/vhost-vdpa.c
Log Message:
-----------
vdpa: trace skipped memory sections
Sometimes, certain parts are not being skipped in
vhost_vdpa_listener_region_del, but they are skipped in
vhost_vdpa_listener_region_add, or vice versa. The vhost-vdpa code
expects all parts to maintain their properties, so we're adding a trace
to help with debugging when any part is skipped.
Signed-off-by: Eugenio Pérez <epere...@redhat.com>
Message-Id: <20240215103616.330518-3-epere...@redhat.com>
Reviewed-by: Michael S. Tsirkin <m...@redhat.com>
Signed-off-by: Michael S. Tsirkin <m...@redhat.com>
Commit: 3a95f572112ab4c789d66af666644adcdb2b45a6
https://github.com/qemu/qemu/commit/3a95f572112ab4c789d66af666644adcdb2b45a6
Author: Jonathan Cameron <jonathan.came...@huawei.com>
Date: 2024-03-12 (Tue, 12 Mar 2024)
Changed paths:
M hw/cxl/cxl-component-utils.c
M hw/pci-bridge/pci_expander_bridge.c
M include/hw/cxl/cxl_component.h
Log Message:
-----------
hw/pci-bridge/pxb-cxl: Drop RAS capability from host bridge.
This CXL component isn't allowed to have a RAS capability.
Whilst this should be harmless as software is not expected to look
here, good to clean it up.
Signed-off-by: Jonathan Cameron <jonathan.came...@huawei.com>
Message-Id: <20240215155206.2736-1-jonathan.came...@huawei.com>
Reviewed-by: Michael S. Tsirkin <m...@redhat.com>
Signed-off-by: Michael S. Tsirkin <m...@redhat.com>
Commit: 633487df8d303b37a88584d5a57a39dbcd91c7bf
https://github.com/qemu/qemu/commit/633487df8d303b37a88584d5a57a39dbcd91c7bf
Author: Volker Rümelin <vr_q...@t-online.de>
Date: 2024-03-12 (Tue, 12 Mar 2024)
Changed paths:
M hw/audio/virtio-snd.c
M include/hw/audio/virtio-snd.h
Log Message:
-----------
hw/audio/virtio-sound: return correct command response size
The payload size returned by command VIRTIO_SND_R_PCM_INFO is
wrong. The code in process_cmd() assumes that all commands
return only a virtio_snd_hdr payload, but some commands like
VIRTIO_SND_R_PCM_INFO may return an additional payload.
Add a zero initialized payload_size variable to struct
virtio_snd_ctrl_command to allow for additional payloads.
Reviewed-by: Marc-André Lureau <marcandre.lur...@redhat.com>
Signed-off-by: Volker Rümelin <vr_q...@t-online.de>
Message-Id: <20240218083351.8524-1-vr_q...@t-online.de>
Reviewed-by: Michael S. Tsirkin <m...@redhat.com>
Signed-off-by: Michael S. Tsirkin <m...@redhat.com>
Commit: 043e127a126bb3ceb5fc753deee27d261fd0c5ce
https://github.com/qemu/qemu/commit/043e127a126bb3ceb5fc753deee27d261fd0c5ce
Author: Albert Esteve <aest...@redhat.com>
Date: 2024-03-12 (Tue, 12 Mar 2024)
Changed paths:
M docs/interop/vhost-user.rst
M hw/virtio/vhost-user.c
Log Message:
-----------
hw/virtio: check owner for removing objects
Shared objects lack spoofing protection.
For VHOST_USER_BACKEND_SHARED_OBJECT_REMOVE messages
received by the vhost-user interface, any backend was
allowed to remove entries from the shared table just
by knowing the UUID. Only the owner of the entry
shall be allowed to removed their resources
from the table.
To fix that, add a check for all
*SHARED_OBJECT_REMOVE messages received.
A vhost device can only remove TYPE_VHOST_DEV
entries that are owned by them, otherwise skip
the removal, and inform the device that the entry
has not been removed in the answer.
Signed-off-by: Albert Esteve <aest...@redhat.com>
Acked-by: Stefan Hajnoczi <stefa...@redhat.com>
Message-Id: <20240219143423.272012-2-aest...@redhat.com>
Reviewed-by: Michael S. Tsirkin <m...@redhat.com>
Signed-off-by: Michael S. Tsirkin <m...@redhat.com>
Reviewed-by: Michael S. Tsirkin <m...@redhat.com>
Signed-off-by: Michael S. Tsirkin <m...@redhat.com>
Commit: cd341fd1ffded978b2aa0b5309b00be7c42e347c
https://github.com/qemu/qemu/commit/cd341fd1ffded978b2aa0b5309b00be7c42e347c
Author: Hao Chen <ch...@yusur.tech>
Date: 2024-03-12 (Tue, 12 Mar 2024)
Changed paths:
M MAINTAINERS
M docs/system/device-emulation.rst
A docs/system/devices/vdpa-net.rst
M hw/net/virtio-net.c
M hw/virtio/virtio-pci.c
M hw/virtio/virtio.c
M include/hw/virtio/virtio-pci.h
M include/hw/virtio/virtio.h
M include/standard-headers/linux/virtio_pci.h
Log Message:
-----------
hw/virtio: Add support for VDPA network simulation devices
This patch adds support for VDPA network simulation devices.
The device is developed based on virtio-net and tap backend,
and supports hardware live migration function.
For more details, please refer to "docs/system/devices/vdpa-net.rst"
Signed-off-by: Hao Chen <ch...@yusur.tech>
Message-Id: <20240221073802.2888022-1-ch...@yusur.tech>
Reviewed-by: Michael S. Tsirkin <m...@redhat.com>
Signed-off-by: Michael S. Tsirkin <m...@redhat.com>
Commit: 2a0e0a35002db7ac64f4e82ea2a4ad2fb6d934b0
https://github.com/qemu/qemu/commit/2a0e0a35002db7ac64f4e82ea2a4ad2fb6d934b0
Author: Zhao Liu <zhao1....@intel.com>
Date: 2024-03-12 (Tue, 12 Mar 2024)
Changed paths:
M hw/cxl/cxl-host.c
Log Message:
-----------
hw/cxl/cxl-host: Fix missing ERRP_GUARD() in cxl_fixed_memory_window_config()
As the comment in qapi/error, dereferencing @errp requires
ERRP_GUARD():
* = Why, when and how to use ERRP_GUARD() =
*
* Without ERRP_GUARD(), use of the @errp parameter is restricted:
* - It must not be dereferenced, because it may be null.
...
* ERRP_GUARD() lifts these restrictions.
*
* To use ERRP_GUARD(), add it right at the beginning of the function.
* @errp can then be used without worrying about the argument being
* NULL or &error_fatal.
*
* Using it when it's not needed is safe, but please avoid cluttering
* the source with useless code.
But in cxl_fixed_memory_window_config(), @errp is dereferenced in 2
places without ERRP_GUARD():
fw->enc_int_ways = cxl_interleave_ways_enc(fw->num_targets, errp);
if (*errp) {
return;
}
and
fw->enc_int_gran =
cxl_interleave_granularity_enc(object->interleave_granularity,
errp);
if (*errp) {
return;
}
For the above 2 places, we check "*errp", because neither function
returns a suitable error code. And since machine_set_cfmw() - the caller
of cxl_fixed_memory_window_config() - doesn't get the NULL @errp
parameter as the "set" method of object property,
cxl_fixed_memory_window_config() hasn't triggered the bug that
dereferencing the NULL @errp.
To follow the requirement of @errp, add missing ERRP_GUARD() in
cxl_fixed_memory_window_config().
Suggested-by: Markus Armbruster <arm...@redhat.com>
Signed-off-by: Zhao Liu <zhao1....@intel.com>
Reviewed-by: Markus Armbruster <arm...@redhat.com>
Message-Id: <20240223085653.1255438-2-zhao1....@linux.intel.com>
Reviewed-by: Michael S. Tsirkin <m...@redhat.com>
Signed-off-by: Michael S. Tsirkin <m...@redhat.com>
Acked-by: Jonathan Cameron <jonathan.came...@huawei.com>
Commit: 5aa4a6417b0f7acbfd7f4c21dca26293bc3d9348
https://github.com/qemu/qemu/commit/5aa4a6417b0f7acbfd7f4c21dca26293bc3d9348
Author: Zhao Liu <zhao1....@intel.com>
Date: 2024-03-12 (Tue, 12 Mar 2024)
Changed paths:
M hw/display/macfb.c
Log Message:
-----------
hw/display/macfb: Fix missing ERRP_GUARD() in macfb_nubus_realize()
As the comment in qapi/error, dereferencing @errp requires
ERRP_GUARD():
* = Why, when and how to use ERRP_GUARD() =
*
* Without ERRP_GUARD(), use of the @errp parameter is restricted:
* - It must not be dereferenced, because it may be null.
...
* ERRP_GUARD() lifts these restrictions.
*
* To use ERRP_GUARD(), add it right at the beginning of the function.
* @errp can then be used without worrying about the argument being
* NULL or &error_fatal.
*
* Using it when it's not needed is safe, but please avoid cluttering
* the source with useless code.
But in macfb_nubus_realize(), @errp is dereferenced without
ERRP_GUARD():
ndc->parent_realize(dev, errp);
if (*errp) {
return;
}
Here we check *errp, because the ndc->parent_realize(), as a
DeviceClass.realize() callback, returns void. And since
macfb_nubus_realize(), also as a DeviceClass.realize(), doesn't get the
NULL @errp parameter, it hasn't triggered the bug that dereferencing the
NULL @errp.
To follow the requirement of @errp, add missing ERRP_GUARD() in
macfb_nubus_realize().
Suggested-by: Markus Armbruster <arm...@redhat.com>
Signed-off-by: Zhao Liu <zhao1....@intel.com>
Reviewed-by: Markus Armbruster <arm...@redhat.com>
Message-Id: <20240223085653.1255438-3-zhao1....@linux.intel.com>
Reviewed-by: Michael S. Tsirkin <m...@redhat.com>
Signed-off-by: Michael S. Tsirkin <m...@redhat.com>
Commit: d477d07a5d2c392c7aa99cb76921ed3e40d141ef
https://github.com/qemu/qemu/commit/d477d07a5d2c392c7aa99cb76921ed3e40d141ef
Author: Zhao Liu <zhao1....@intel.com>
Date: 2024-03-12 (Tue, 12 Mar 2024)
Changed paths:
M hw/mem/cxl_type3.c
Log Message:
-----------
hw/mem/cxl_type3: Fix missing ERRP_GUARD() in ct3_realize()
As the comment in qapi/error, dereferencing @errp requires
ERRP_GUARD():
* = Why, when and how to use ERRP_GUARD() =
*
* Without ERRP_GUARD(), use of the @errp parameter is restricted:
* - It must not be dereferenced, because it may be null.
...
* ERRP_GUARD() lifts these restrictions.
*
* To use ERRP_GUARD(), add it right at the beginning of the function.
* @errp can then be used without worrying about the argument being
* NULL or &error_fatal.
*
* Using it when it's not needed is safe, but please avoid cluttering
* the source with useless code.
But in ct3_realize(), @errp is dereferenced without ERRP_GUARD():
cxl_doe_cdat_init(cxl_cstate, errp);
if (*errp) {
goto err_free_special_ops;
}
Here we check *errp, because cxl_doe_cdat_init() returns void. And
ct3_realize() - as a PCIDeviceClass.realize() method - doesn't get the
NULL @errp parameter, it hasn't triggered the bug that dereferencing
the NULL @errp.
To follow the requirement of @errp, add missing ERRP_GUARD() in
ct3_realize().
Suggested-by: Markus Armbruster <arm...@redhat.com>
Signed-off-by: Zhao Liu <zhao1....@intel.com>
Reviewed-by: Markus Armbruster <arm...@redhat.com>
Message-Id: <20240223085653.1255438-4-zhao1....@linux.intel.com>
Reviewed-by: Michael S. Tsirkin <m...@redhat.com>
Signed-off-by: Michael S. Tsirkin <m...@redhat.com>
Acked-by: Jonathan Cameron <jonathan.came...@huawei.com>
Commit: 305446015848f0b5d71b817b53e7e02b08c36ede
https://github.com/qemu/qemu/commit/305446015848f0b5d71b817b53e7e02b08c36ede
Author: Zhao Liu <zhao1....@intel.com>
Date: 2024-03-12 (Tue, 12 Mar 2024)
Changed paths:
M hw/misc/xlnx-versal-trng.c
Log Message:
-----------
hw/misc/xlnx-versal-trng: Check returned bool in trng_prop_fault_event_set()
As the comment in qapi/error, dereferencing @errp requires
ERRP_GUARD():
* = Why, when and how to use ERRP_GUARD() =
*
* Without ERRP_GUARD(), use of the @errp parameter is restricted:
* - It must not be dereferenced, because it may be null.
...
* ERRP_GUARD() lifts these restrictions.
*
* To use ERRP_GUARD(), add it right at the beginning of the function.
* @errp can then be used without worrying about the argument being
* NULL or &error_fatal.
*
* Using it when it's not needed is safe, but please avoid cluttering
* the source with useless code.
But in trng_prop_fault_event_set, @errp is dereferenced without
ERRP_GUARD():
visit_type_uint32(v, name, events, errp);
if (*errp) {
return;
}
Currently, since trng_prop_fault_event_set() doesn't get the NULL @errp
parameter as a "set" method of object property, it hasn't triggered the
bug that dereferencing the NULL @errp.
And since visit_type_uint32() returns bool, check the returned bool
directly instead of dereferencing @errp, then we needn't the add missing
ERRP_GUARD().
Suggested-by: Markus Armbruster <arm...@redhat.com>
Signed-off-by: Zhao Liu <zhao1....@intel.com>
Message-Id: <20240223085653.1255438-5-zhao1....@linux.intel.com>
Reviewed-by: Michael S. Tsirkin <m...@redhat.com>
Signed-off-by: Michael S. Tsirkin <m...@redhat.com>
Reviewed-by: Philippe Mathieu-Daudé <phi...@linaro.org>
Commit: 4f5a3f49b934ff24227ebc95b3f9177f0147ff52
https://github.com/qemu/qemu/commit/4f5a3f49b934ff24227ebc95b3f9177f0147ff52
Author: Zhao Liu <zhao1....@intel.com>
Date: 2024-03-12 (Tue, 12 Mar 2024)
Changed paths:
M hw/pci-bridge/cxl_upstream.c
Log Message:
-----------
hw/pci-bridge/cxl_upstream: Fix missing ERRP_GUARD() in cxl_usp_realize()
As the comment in qapi/error, dereferencing @errp requires
ERRP_GUARD():
* = Why, when and how to use ERRP_GUARD() =
*
* Without ERRP_GUARD(), use of the @errp parameter is restricted:
* - It must not be dereferenced, because it may be null.
...
* ERRP_GUARD() lifts these restrictions.
*
* To use ERRP_GUARD(), add it right at the beginning of the function.
* @errp can then be used without worrying about the argument being
* NULL or &error_fatal.
*
* Using it when it's not needed is safe, but please avoid cluttering
* the source with useless code.
But in cxl_usp_realize(), @errp is dereferenced without ERRP_GUARD():
cxl_doe_cdat_init(cxl_cstate, errp);
if (*errp) {
goto err_cap;
}
Here we check *errp, because cxl_doe_cdat_init() returns void. And since
cxl_usp_realize() - as a PCIDeviceClass.realize() method - doesn't get
the NULL @errp parameter, it hasn't triggered the bug that dereferencing
the NULL @errp.
To follow the requirement of @errp, add missing ERRP_GUARD() in
cxl_usp_realize().
Suggested-by: Markus Armbruster <arm...@redhat.com>
Signed-off-by: Zhao Liu <zhao1....@intel.com>
Reviewed-by: Markus Armbruster <arm...@redhat.com>
Message-Id: <20240223085653.1255438-6-zhao1....@linux.intel.com>
Reviewed-by: Michael S. Tsirkin <m...@redhat.com>
Signed-off-by: Michael S. Tsirkin <m...@redhat.com>
Acked-by: Jonathan Cameron <jonathan.came...@huawei.com>
Reviewed-by: Thomas Huth <th...@redhat.com>
Commit: ccd1fd0c5d4f4cba7fa8642ab466a82db3e9f093
https://github.com/qemu/qemu/commit/ccd1fd0c5d4f4cba7fa8642ab466a82db3e9f093
Author: Zhao Liu <zhao1....@intel.com>
Date: 2024-03-12 (Tue, 12 Mar 2024)
Changed paths:
M hw/vfio/iommufd.c
Log Message:
-----------
hw/vfio/iommufd: Fix missing ERRP_GUARD() in iommufd_cdev_getfd()
As the comment in qapi/error, dereferencing @errp requires
ERRP_GUARD():
* = Why, when and how to use ERRP_GUARD() =
*
* Without ERRP_GUARD(), use of the @errp parameter is restricted:
* - It must not be dereferenced, because it may be null.
...
* ERRP_GUARD() lifts these restrictions.
*
* To use ERRP_GUARD(), add it right at the beginning of the function.
* @errp can then be used without worrying about the argument being
* NULL or &error_fatal.
*
* Using it when it's not needed is safe, but please avoid cluttering
* the source with useless code.
But in iommufd_cdev_getfd(), @errp is dereferenced without ERRP_GUARD():
if (*errp) {
error_prepend(errp, VFIO_MSG_PREFIX, path);
}
Currently, since vfio_attach_device() - the caller of
iommufd_cdev_getfd() - is always called in DeviceClass.realize() context
and doesn't get the NULL @errp parameter, iommufd_cdev_getfd()
hasn't triggered the bug that dereferencing the NULL @errp.
To follow the requirement of @errp, add missing ERRP_GUARD() in
iommufd_cdev_getfd().
Suggested-by: Markus Armbruster <arm...@redhat.com>
Signed-off-by: Zhao Liu <zhao1....@intel.com>
Reviewed-by: Markus Armbruster <arm...@redhat.com>
Message-Id: <20240223085653.1255438-7-zhao1....@linux.intel.com>
Reviewed-by: Michael S. Tsirkin <m...@redhat.com>
Signed-off-by: Michael S. Tsirkin <m...@redhat.com>
Commit: 0f9c30350bdf9d062609a15124f30f6c2b0a4b60
https://github.com/qemu/qemu/commit/0f9c30350bdf9d062609a15124f30f6c2b0a4b60
Author: Zhao Liu <zhao1....@intel.com>
Date: 2024-03-12 (Tue, 12 Mar 2024)
Changed paths:
M hw/intc/ioapic_common.c
Log Message:
-----------
hw/intc: Check @errp to handle the error of IOAPICCommonClass.realize()
IOAPICCommonClass implements its own private realize(), and this private
realize() allows error.
Since IOAPICCommonClass.realize() returns void, to check the error,
dereference @errp with ERRP_GUARD().
Signed-off-by: Zhao Liu <zhao1....@intel.com>
Message-Id: <20240223085653.1255438-8-zhao1....@linux.intel.com>
Reviewed-by: Michael S. Tsirkin <m...@redhat.com>
Signed-off-by: Michael S. Tsirkin <m...@redhat.com>
Reviewed-by: Philippe Mathieu-Daudé <phi...@linaro.org>
Commit: 735eee07d1f963635d3c3bf9f5e4bf1bc000870e
https://github.com/qemu/qemu/commit/735eee07d1f963635d3c3bf9f5e4bf1bc000870e
Author: Felix Wu <f...@google.com>
Date: 2024-03-12 (Tue, 12 Mar 2024)
Changed paths:
M hw/smbios/smbios.c
M include/hw/firmware/smbios.h
M qemu-options.hx
Log Message:
-----------
Implement base of SMBIOS type 9 descriptor.
Version 2.1+.
Signed-off-by: Felix Wu <f...@google.com>
Signed-off-by: Nabih Estefan <nabiheste...@google.com>
Message-Id: <20240221170027.1027325-2-nabiheste...@google.com>
Reviewed-by: Michael S. Tsirkin <m...@redhat.com>
Signed-off-by: Michael S. Tsirkin <m...@redhat.com>
Commit: 04f143d828845d0fd52dd4a52664d81a4f5431f7
https://github.com/qemu/qemu/commit/04f143d828845d0fd52dd4a52664d81a4f5431f7
Author: Felix Wu <f...@google.com>
Date: 2024-03-12 (Tue, 12 Mar 2024)
Changed paths:
M hw/smbios/smbios.c
M include/hw/firmware/smbios.h
M qemu-options.hx
Log Message:
-----------
Implement SMBIOS type 9 v2.6
Signed-off-by: Felix Wu <f...@google.com>
Signed-off-by: Nabih Estefan <nabiheste...@google.com>
Message-Id: <20240221170027.1027325-3-nabiheste...@google.com>
Reviewed-by: Michael S. Tsirkin <m...@redhat.com>
Signed-off-by: Michael S. Tsirkin <m...@redhat.com>
Commit: 91bb64a8d2014fda33a81fcf0fce37340f0d3b0c
https://github.com/qemu/qemu/commit/91bb64a8d2014fda33a81fcf0fce37340f0d3b0c
Author: Akihiko Odaki <akihiko.od...@daynix.com>
Date: 2024-03-12 (Tue, 12 Mar 2024)
Changed paths:
M hw/nvme/ctrl.c
Log Message:
-----------
hw/nvme: Use pcie_sriov_num_vfs()
nvme_sriov_pre_write_ctrl() used to directly inspect SR-IOV
configurations to know the number of VFs being disabled due to SR-IOV
configuration writes, but the logic was flawed and resulted in
out-of-bound memory access.
It assumed PCI_SRIOV_NUM_VF always has the number of currently enabled
VFs, but it actually doesn't in the following cases:
- PCI_SRIOV_NUM_VF has been set but PCI_SRIOV_CTRL_VFE has never been.
- PCI_SRIOV_NUM_VF was written after PCI_SRIOV_CTRL_VFE was set.
- VFs were only partially enabled because of realization failure.
It is a responsibility of pcie_sriov to interpret SR-IOV configurations
and pcie_sriov does it correctly, so use pcie_sriov_num_vfs(), which it
provides, to get the number of enabled VFs before and after SR-IOV
configuration writes.
Cc: qemu-sta...@nongnu.org
Fixes: CVE-2024-26328
Fixes: 11871f53ef8e ("hw/nvme: Add support for the Virtualization Management
command")
Suggested-by: Michael S. Tsirkin <m...@redhat.com>
Signed-off-by: Akihiko Odaki <akihiko.od...@daynix.com>
Message-Id: <20240228-reuse-v8-1-282660281...@daynix.com>
Reviewed-by: Michael S. Tsirkin <m...@redhat.com>
Signed-off-by: Michael S. Tsirkin <m...@redhat.com>
Commit: 6081b4243cd64dff1b2cf5b0c215c71e9d7e753b
https://github.com/qemu/qemu/commit/6081b4243cd64dff1b2cf5b0c215c71e9d7e753b
Author: Akihiko Odaki <akihiko.od...@daynix.com>
Date: 2024-03-12 (Tue, 12 Mar 2024)
Changed paths:
M hw/pci/pcie_sriov.c
Log Message:
-----------
pcie_sriov: Validate NumVFs
The guest may write NumVFs greater than TotalVFs and that can lead
to buffer overflow in VF implementations.
Cc: qemu-sta...@nongnu.org
Fixes: CVE-2024-26327
Fixes: 7c0fa8dff811 ("pcie: Add support for Single Root I/O Virtualization
(SR/IOV)")
Signed-off-by: Akihiko Odaki <akihiko.od...@daynix.com>
Message-Id: <20240228-reuse-v8-2-282660281...@daynix.com>
Reviewed-by: Michael S. Tsirkin <m...@redhat.com>
Signed-off-by: Michael S. Tsirkin <m...@redhat.com>
Reviewed-by: Sriram Yagnaraman <sriram.yagnara...@ericsson.com>
Commit: c8bc4db403e17663b69d811e69f88c9dfc6f7be2
https://github.com/qemu/qemu/commit/c8bc4db403e17663b69d811e69f88c9dfc6f7be2
Author: Akihiko Odaki <akihiko.od...@daynix.com>
Date: 2024-03-12 (Tue, 12 Mar 2024)
Changed paths:
M hw/net/igb.c
M hw/nvme/ctrl.c
M hw/pci/pcie_sriov.c
M include/hw/pci/pcie_sriov.h
Log Message:
-----------
pcie_sriov: Reset SR-IOV extended capability
pcie_sriov_pf_disable_vfs() is called when resetting the PF, but it only
disables VFs and does not reset SR-IOV extended capability, leaking the
state and making the VF Enable register inconsistent with the actual
state.
Replace pcie_sriov_pf_disable_vfs() with pcie_sriov_pf_reset(), which
does not only disable VFs but also resets the capability.
Signed-off-by: Akihiko Odaki <akihiko.od...@daynix.com>
Message-Id: <20240228-reuse-v8-3-282660281...@daynix.com>
Reviewed-by: Michael S. Tsirkin <m...@redhat.com>
Signed-off-by: Michael S. Tsirkin <m...@redhat.com>
Reviewed-by: Sriram Yagnaraman <sriram.yagnara...@ericsson.com>
Commit: 63eb76dda237843582f3616f4403ae795e471e17
https://github.com/qemu/qemu/commit/63eb76dda237843582f3616f4403ae795e471e17
Author: Akihiko Odaki <akihiko.od...@daynix.com>
Date: 2024-03-12 (Tue, 12 Mar 2024)
Changed paths:
M hw/pci/pcie_sriov.c
Log Message:
-----------
pcie_sriov: Do not reset NumVFs after disabling VFs
The spec does not NumVFs is reset after disabling VFs except when
resetting the PF. Clearing it is guest visible and out of spec, even
though Linux doesn't rely on this value being preserved, so we never
noticed.
Fixes: 7c0fa8dff811 ("pcie: Add support for Single Root I/O Virtualization
(SR/IOV)")
Signed-off-by: Akihiko Odaki <akihiko.od...@daynix.com>
Message-Id: <20240228-reuse-v8-4-282660281...@daynix.com>
Reviewed-by: Michael S. Tsirkin <m...@redhat.com>
Signed-off-by: Michael S. Tsirkin <m...@redhat.com>
Commit: 1a909e3dd85d5c57a0e6a7e3285a29e57574f80d
https://github.com/qemu/qemu/commit/1a909e3dd85d5c57a0e6a7e3285a29e57574f80d
Author: Akihiko Odaki <akihiko.od...@daynix.com>
Date: 2024-03-12 (Tue, 12 Mar 2024)
Changed paths:
M hw/net/igb.c
M hw/nvme/ctrl.c
M hw/pci/pci.c
Log Message:
-----------
hw/pci: Always call pcie_sriov_pf_reset()
Call pcie_sriov_pf_reset() from pci_do_device_reset() just as we do
for msi_reset() and msix_reset() to prevent duplicating code for each
SR-IOV PF.
Signed-off-by: Akihiko Odaki <akihiko.od...@daynix.com>
Message-Id: <20240228-reuse-v8-5-282660281...@daynix.com>
Reviewed-by: Michael S. Tsirkin <m...@redhat.com>
Signed-off-by: Michael S. Tsirkin <m...@redhat.com>
Reviewed-by: Sriram Yagnaraman <sriram.yagnara...@ericsson.com>
Commit: e4e98c7eebfab0f844784cdf5c108bb3d60ac9a2
https://github.com/qemu/qemu/commit/e4e98c7eebfab0f844784cdf5c108bb3d60ac9a2
Author: Ani Sinha <anisi...@redhat.com>
Date: 2024-03-12 (Tue, 12 Mar 2024)
Changed paths:
M hw/i386/pc_q35.c
Log Message:
-----------
pc: q35: Bump max_cpus to 4096 vcpus
Since commit f10a570b093e6 ("KVM: x86: Add CONFIG_KVM_MAX_NR_VCPUS to allow up
to 4096 vCPUs")
Linux kernel can support upto a maximum number of 4096 vcpus when MAXSMP is
enabled in the kernel. At present, QEMU has been tested to correctly boot a
linux guest with 4096 vcpus using the current edk2 upstream master branch that
has the fixes corresponding to the following two PRs:
https://github.com/tianocore/edk2/pull/5410
https://github.com/tianocore/edk2/pull/5418
The changes merged into edk2 with the above PRs will be in the upcoming 2024-05
release. With current seabios firmware, it boots fine with 4096 vcpus already.
So bump up the value max_cpus to 4096 for q35 machines versions 9 and newer.
Q35 machines versions 8.2 and older continue to support 1024 maximum vcpus
as before for compatibility reasons.
If KVM is not able to support the specified number of vcpus, QEMU would
return the following error messages:
$ ./qemu-system-x86_64 -cpu host -accel kvm -machine q35 -smp 1728
qemu-system-x86_64: -accel kvm: warning: Number of SMP cpus requested (1728)
exceeds the recommended cpus supported by KVM (12)
qemu-system-x86_64: -accel kvm: warning: Number of hotpluggable cpus requested
(1728) exceeds the recommended cpus supported by KVM (12)
Number of SMP cpus requested (1728) exceeds the maximum cpus supported by KVM
(1024)
Cc: Daniel P. Berrangé <berra...@redhat.com>
Cc: Igor Mammedov <imamm...@redhat.com>
Cc: Michael S. Tsirkin <m...@redhat.com>
Cc: Julia Suvorova <jus...@redhat.com>
Cc: kra...@redhat.com
Reviewed-by: Daniel P. Berrangé <berra...@redhat.com>
Reviewed-by: Igor Mammedov <imamm...@redhat.com>
Reviewed-by: Gerd Hoffmann <kra...@redhat.com>
Signed-off-by: Ani Sinha <anisi...@redhat.com>
Message-Id: <20240228143351.3967-1-anisi...@redhat.com>
Reviewed-by: Zhao Liu <zhao1....@intel.com>
Reviewed-by: Michael S. Tsirkin <m...@redhat.com>
Signed-off-by: Michael S. Tsirkin <m...@redhat.com>
Commit: 0fbe8d7c4c7e44fc86986217dc3ab65ec4e6a302
https://github.com/qemu/qemu/commit/0fbe8d7c4c7e44fc86986217dc3ab65ec4e6a302
Author: Bernhard Beschow <shen...@gmail.com>
Date: 2024-03-12 (Tue, 12 Mar 2024)
Changed paths:
M hw/i386/pc_sysfw.c
Log Message:
-----------
Revert "hw/i386/pc_sysfw: Inline pc_system_flash_create() and remove it"
Commit 6f6ad2b24582 "hw/i386/pc: Confine system flash handling to pc_sysfw"
causes a regression when specifying the property `-M pflash0` in the PCI PC
machines:
qemu-system-x86_64: Property 'pc-q35-9.0-machine.pflash0' not found
In order to revert the commit, the commit below must be reverted first.
This reverts commit cb05cc16029bb0a61ac5279ab7b3b90dcf2aa69f.
Signed-off-by: Bernhard Beschow <shen...@gmail.com>
Message-Id: <20240226215909.30884-2-shen...@gmail.com>
Tested-by: Alex Williamson <alex.william...@redhat.com>
Reviewed-by: Michael S. Tsirkin <m...@redhat.com>
Signed-off-by: Michael S. Tsirkin <m...@redhat.com>
Commit: f2cb9f34ad8591a7530ecec856f2302bb3efd71e
https://github.com/qemu/qemu/commit/f2cb9f34ad8591a7530ecec856f2302bb3efd71e
Author: Bernhard Beschow <shen...@gmail.com>
Date: 2024-03-12 (Tue, 12 Mar 2024)
Changed paths:
M hw/i386/pc.c
M hw/i386/pc_piix.c
M hw/i386/pc_sysfw.c
M include/hw/i386/pc.h
Log Message:
-----------
Revert "hw/i386/pc: Confine system flash handling to pc_sysfw"
Specifying the property `-M pflash0` results in a regression:
qemu-system-x86_64: Property 'pc-q35-9.0-machine.pflash0' not found
Revert the change for now until a solution is found.
This reverts commit 6f6ad2b24582593d8feb00434ce2396840666227.
Reported-by: Volker Rümelin <vr_q...@t-online.de>
Signed-off-by: Bernhard Beschow <shen...@gmail.com>
Message-Id: <20240226215909.30884-3-shen...@gmail.com>
Tested-by: Alex Williamson <alex.william...@redhat.com>
Reviewed-by: Michael S. Tsirkin <m...@redhat.com>
Signed-off-by: Michael S. Tsirkin <m...@redhat.com>
Commit: 6cd2b093e771ee606b4e065f615d9b2fafd76d22
https://github.com/qemu/qemu/commit/6cd2b093e771ee606b4e065f615d9b2fafd76d22
Author: Bernhard Beschow <shen...@gmail.com>
Date: 2024-03-12 (Tue, 12 Mar 2024)
Changed paths:
M hw/i386/pc.c
Log Message:
-----------
hw/i386/pc: Remove "rtc_state" link again
Commit 99e1c1137b6f "hw/i386/pc: Populate RTC attribute directly" made linking
the "rtc_state" property unnecessary and removed it. Commit 84e945aad2d0 "vl,
pc: turn -no-fd-bootchk into a machine property" accidently reintroduced the
link. Remove it again since it is not needed.
Fixes: 84e945aad2d0 "vl, pc: turn -no-fd-bootchk into a machine property"
Cc: Paolo Bonzini <pbonz...@redhat.com>
Signed-off-by: Bernhard Beschow <shen...@gmail.com>
Message-Id: <20240303185332.1408-2-shen...@gmail.com>
Reviewed-by: Michael S. Tsirkin <m...@redhat.com>
Signed-off-by: Michael S. Tsirkin <m...@redhat.com>
Reviewed-by: Philippe Mathieu-Daudé <phi...@linaro.org>
Commit: 6605d09791df7387c3e82c9554731a752789987e
https://github.com/qemu/qemu/commit/6605d09791df7387c3e82c9554731a752789987e
Author: Bernhard Beschow <shen...@gmail.com>
Date: 2024-03-12 (Tue, 12 Mar 2024)
Changed paths:
M hw/i386/pc.c
Log Message:
-----------
hw/i386/pc: Avoid one use of the current_machine global
The RTC can be accessed through the X86 machine instance, so rather than passing
the RTC it's possible to pass the machine state instead. This avoids
pc_boot_set() from having to access the current_machine global.
Signed-off-by: Bernhard Beschow <shen...@gmail.com>
Message-Id: <20240303185332.1408-3-shen...@gmail.com>
Reviewed-by: Michael S. Tsirkin <m...@redhat.com>
Signed-off-by: Michael S. Tsirkin <m...@redhat.com>
Reviewed-by: Philippe Mathieu-Daudé <phi...@linaro.org>
Commit: c5e2d74448433c3d800dca6160b5c8fbd76c67d8
https://github.com/qemu/qemu/commit/c5e2d74448433c3d800dca6160b5c8fbd76c67d8
Author: Bernhard Beschow <shen...@gmail.com>
Date: 2024-03-12 (Tue, 12 Mar 2024)
Changed paths:
M hw/i386/pc.c
Log Message:
-----------
hw/i386/pc: Set "normal" boot device order in pc_basic_device_init()
The boot device order may change during the lifetime of a VM. Usually, the
"normal" order is set once during machine init(). However, if a user specifies
`-boot once=...`, the "normal" order is overwritten by the "once" order just
before machine_done, and a reset handler is registered which restores the
"normal" order during the next reset.
In the next patch, pc_cmos_init() will be inlined into pc_cmos_init_late() which
runs during machine_done. This means that the "once" boot order would be
overwritten again with the "normal" boot order -- which renders the user's
choice ineffective. Fix this by setting the "normal" boot order in
pc_basic_device_init() which already registers the boot_set() handler.
Signed-off-by: Bernhard Beschow <shen...@gmail.com>
Message-Id: <20240303185332.1408-4-shen...@gmail.com>
Reviewed-by: Michael S. Tsirkin <m...@redhat.com>
Signed-off-by: Michael S. Tsirkin <m...@redhat.com>
Commit: 7d12305ec8c3fa8c60b39aae0d952245a62696d4
https://github.com/qemu/qemu/commit/7d12305ec8c3fa8c60b39aae0d952245a62696d4
Author: Bernhard Beschow <shen...@gmail.com>
Date: 2024-03-12 (Tue, 12 Mar 2024)
Changed paths:
M hw/i386/pc.c
M hw/i386/pc_piix.c
M hw/i386/pc_q35.c
M include/hw/i386/pc.h
Log Message:
-----------
hw/i386/pc: Inline pc_cmos_init() into pc_cmos_init_late() and remove it
Now that pc_cmos_init() doesn't populate the X86MachineState::rtc attribute any
longer, its duties can be merged into pc_cmos_init_late() which is called within
machine_done notifier. This frees pc_piix and pc_q35 from explicit CMOS
initialization.
Signed-off-by: Bernhard Beschow <shen...@gmail.com>
Message-Id: <20240303185332.1408-5-shen...@gmail.com>
Reviewed-by: Michael S. Tsirkin <m...@redhat.com>
Signed-off-by: Michael S. Tsirkin <m...@redhat.com>
Commit: b64b7ed8bb5d475eab3b4188ef0076e332937c62
https://github.com/qemu/qemu/commit/b64b7ed8bb5d475eab3b4188ef0076e332937c62
Author: Ankit Agrawal <ank...@nvidia.com>
Date: 2024-03-12 (Tue, 12 Mar 2024)
Changed paths:
A hw/acpi/acpi_generic_initiator.c
M hw/acpi/meson.build
A include/hw/acpi/acpi_generic_initiator.h
M qapi/qom.json
Log Message:
-----------
qom: new object to associate device to NUMA node
NVIDIA GPU's support MIG (Mult-Instance GPUs) feature [1], which allows
partitioning of the GPU device resources (including device memory) into
several (upto 8) isolated instances. Each of the partitioned memory needs
a dedicated NUMA node to operate. The partitions are not fixed and they
can be created/deleted at runtime.
Unfortunately Linux OS does not provide a means to dynamically create/destroy
NUMA nodes and such feature implementation is not expected to be trivial. The
nodes that OS discovers at the boot time while parsing SRAT remains fixed. So
we utilize the Generic Initiator (GI) Affinity structures that allows
association between nodes and devices. Multiple GI structures per BDF is
possible, allowing creation of multiple nodes by exposing unique PXM in each
of these structures.
Implement the mechanism to build the GI affinity structures as Qemu currently
does not. Introduce a new acpi-generic-initiator object to allow host admin
link a device with an associated NUMA node. Qemu maintains this association
and use this object to build the requisite GI Affinity Structure.
When multiple NUMA nodes are associated with a device, it is required to
create those many number of acpi-generic-initiator objects, each representing
a unique device:node association.
Following is one of a decoded GI affinity structure in VM ACPI SRAT.
[0C8h 0200 1] Subtable Type : 05 [Generic Initiator Affinity]
[0C9h 0201 1] Length : 20
[0CAh 0202 1] Reserved1 : 00
[0CBh 0203 1] Device Handle Type : 01
[0CCh 0204 4] Proximity Domain : 00000007
[0D0h 0208 16] Device Handle : 00 00 20 00 00 00 00 00 00 00 00
00 00 00 00 00
[0E0h 0224 4] Flags (decoded below) : 00000001
Enabled : 1
[0E4h 0228 4] Reserved2 : 00000000
[0E8h 0232 1] Subtable Type : 05 [Generic Initiator Affinity]
[0E9h 0233 1] Length : 20
An admin can provide a range of acpi-generic-initiator objects, each
associating a device (by providing the id through pci-dev argument)
to the desired NUMA node (using the node argument). Currently, only PCI
device is supported.
For the grace hopper system, create a range of 8 nodes and associate that
with the device using the acpi-generic-initiator object. While a configuration
of less than 8 nodes per device is allowed, such configuration will prevent
utilization of the feature to the fullest. The following sample creates 8
nodes per PCI device for a VM with 2 PCI devices and link them to the
respecitve PCI device using acpi-generic-initiator objects:
-numa node,nodeid=2 -numa node,nodeid=3 -numa node,nodeid=4 \
-numa node,nodeid=5 -numa node,nodeid=6 -numa node,nodeid=7 \
-numa node,nodeid=8 -numa node,nodeid=9 \
-device
vfio-pci-nohotplug,host=0009:01:00.0,bus=pcie.0,addr=04.0,rombar=0,id=dev0 \
-object acpi-generic-initiator,id=gi0,pci-dev=dev0,node=2 \
-object acpi-generic-initiator,id=gi1,pci-dev=dev0,node=3 \
-object acpi-generic-initiator,id=gi2,pci-dev=dev0,node=4 \
-object acpi-generic-initiator,id=gi3,pci-dev=dev0,node=5 \
-object acpi-generic-initiator,id=gi4,pci-dev=dev0,node=6 \
-object acpi-generic-initiator,id=gi5,pci-dev=dev0,node=7 \
-object acpi-generic-initiator,id=gi6,pci-dev=dev0,node=8 \
-object acpi-generic-initiator,id=gi7,pci-dev=dev0,node=9 \
-numa node,nodeid=10 -numa node,nodeid=11 -numa node,nodeid=12 \
-numa node,nodeid=13 -numa node,nodeid=14 -numa node,nodeid=15 \
-numa node,nodeid=16 -numa node,nodeid=17 \
-device
vfio-pci-nohotplug,host=0009:01:01.0,bus=pcie.0,addr=05.0,rombar=0,id=dev1 \
-object acpi-generic-initiator,id=gi8,pci-dev=dev1,node=10 \
-object acpi-generic-initiator,id=gi9,pci-dev=dev1,node=11 \
-object acpi-generic-initiator,id=gi10,pci-dev=dev1,node=12 \
-object acpi-generic-initiator,id=gi11,pci-dev=dev1,node=13 \
-object acpi-generic-initiator,id=gi12,pci-dev=dev1,node=14 \
-object acpi-generic-initiator,id=gi13,pci-dev=dev1,node=15 \
-object acpi-generic-initiator,id=gi14,pci-dev=dev1,node=16 \
-object acpi-generic-initiator,id=gi15,pci-dev=dev1,node=17 \
Link: https://www.nvidia.com/en-in/technologies/multi-instance-gpu [1]
Cc: Jonathan Cameron <qemu-de...@nongnu.org>
Cc: Alex Williamson <alex.william...@redhat.com>
Cc: Markus Armbruster <arm...@redhat.com>
Reviewed-by: Jonathan Cameron <jonathan.came...@huawei.com>
Acked-by: Markus Armbruster <arm...@redhat.com>
Signed-off-by: Ankit Agrawal <ank...@nvidia.com>
Message-Id: <20240308145525.10886-2-ank...@nvidia.com>
Reviewed-by: Michael S. Tsirkin <m...@redhat.com>
Signed-off-by: Michael S. Tsirkin <m...@redhat.com>
Commit: 0a5b5acdf2d8c7302ca48d42e6ef3423e1b956d5
https://github.com/qemu/qemu/commit/0a5b5acdf2d8c7302ca48d42e6ef3423e1b956d5
Author: Ankit Agrawal <ank...@nvidia.com>
Date: 2024-03-12 (Tue, 12 Mar 2024)
Changed paths:
M hw/acpi/acpi_generic_initiator.c
M hw/acpi/hmat.c
M hw/arm/virt-acpi-build.c
M hw/core/numa.c
M include/hw/acpi/acpi_generic_initiator.h
M include/sysemu/numa.h
Log Message:
-----------
hw/acpi: Implement the SRAT GI affinity structure
ACPI spec provides a scheme to associate "Generic Initiators" [1]
(e.g. heterogeneous processors and accelerators, GPUs, and I/O devices with
integrated compute or DMA engines GPUs) with Proximity Domains. This is
achieved using Generic Initiator Affinity Structure in SRAT. During bootup,
Linux kernel parse the ACPI SRAT to determine the PXM ids and create a NUMA
node for each unique PXM ID encountered. Qemu currently do not implement
these structures while building SRAT.
Add GI structures while building VM ACPI SRAT. The association between
device and node are stored using acpi-generic-initiator object. Lookup
presence of all such objects and use them to build these structures.
The structure needs a PCI device handle [2] that consists of the device BDF.
The vfio-pci device corresponding to the acpi-generic-initiator object is
located to determine the BDF.
[1] ACPI Spec 6.3, Section 5.2.16.6
[2] ACPI Spec 6.3, Table 5.80
Cc: Jonathan Cameron <qemu-de...@nongnu.org>
Cc: Alex Williamson <alex.william...@redhat.com>
Cc: Cedric Le Goater <c...@redhat.com>
Reviewed-by: Jonathan Cameron <jonathan.came...@huawei.com>
Signed-off-by: Ankit Agrawal <ank...@nvidia.com>
Message-Id: <20240308145525.10886-3-ank...@nvidia.com>
Reviewed-by: Michael S. Tsirkin <m...@redhat.com>
Signed-off-by: Michael S. Tsirkin <m...@redhat.com>
Commit: 5deced6a13de9409fd9114432b25072189a68942
https://github.com/qemu/qemu/commit/5deced6a13de9409fd9114432b25072189a68942
Author: Ankit Agrawal <ank...@nvidia.com>
Date: 2024-03-12 (Tue, 12 Mar 2024)
Changed paths:
M hw/i386/acpi-build.c
Log Message:
-----------
hw/i386/acpi-build: Add support for SRAT Generic Initiator structures
The acpi-generic-initiator object is added to allow a host device
to be linked with a NUMA node. Qemu use it to build the SRAT
Generic Initiator Affinity structure [1]. Add support for i386.
[1] ACPI Spec 6.3, Section 5.2.16.6
Suggested-by: Jonathan Cameron <jonathan.came...@huawei.com>
Signed-off-by: Ankit Agrawal <ank...@nvidia.com>
Message-Id: <20240308145525.10886-4-ank...@nvidia.com>
Reviewed-by: Michael S. Tsirkin <m...@redhat.com>
Signed-off-by: Michael S. Tsirkin <m...@redhat.com>
Reviewed-by: Jonathan Cameron <jonathan.came...@huawei.com>
Commit: 294ac5fef3aa78111de07357734285744103f47c
https://github.com/qemu/qemu/commit/294ac5fef3aa78111de07357734285744103f47c
Author: Eric Auger <eric.au...@redhat.com>
Date: 2024-03-12 (Tue, 12 Mar 2024)
Changed paths:
M hw/virtio/virtio-iommu.c
M include/hw/virtio/virtio-iommu.h
Log Message:
-----------
virtio-iommu: Add a granule property
This allows to choose which granule will be used by
default by the virtio-iommu. Current page size mask
default is qemu_target_page_mask so this translates
into a 4k granule on ARM and x86_64 where virtio-iommu
is supported.
Signed-off-by: Eric Auger <eric.au...@redhat.com>
Reviewed-by: Philippe Mathieu-Daudé <phi...@linaro.org>
Reviewed-by: Zhenzhong Duan <zhenzhong.d...@intel.com>
Message-Id: <20240307134445.92296-3-eric.au...@redhat.com>
Reviewed-by: Michael S. Tsirkin <m...@redhat.com>
Signed-off-by: Michael S. Tsirkin <m...@redhat.com>
Commit: 9dd5e808fc17ac92180965178a6e867c1e96ac57
https://github.com/qemu/qemu/commit/9dd5e808fc17ac92180965178a6e867c1e96ac57
Author: Eric Auger <eric.au...@redhat.com>
Date: 2024-03-12 (Tue, 12 Mar 2024)
Changed paths:
M hw/core/machine.c
M hw/virtio/virtio-iommu.c
Log Message:
-----------
virtio-iommu: Change the default granule to the host page size
We used to set the default granule to 4KB but with VFIO assignment
it makes more sense to use the actual host page size.
Indeed when hotplugging a VFIO device protected by a virtio-iommu
on a 64kB/64kB host/guest config, we current get a qemu crash:
"vfio: DMA mapping failed, unable to continue"
This is due to the hot-attached VFIO device calling
memory_region_iommu_set_page_size_mask() with 64kB granule
whereas the virtio-iommu granule was already frozen to 4KB on
machine init done.
Set the granule property to "host" and introduce a new compat.
The page size mask used before 9.0 was qemu_target_page_mask().
Since the virtio-iommu currently only supports x86_64 and aarch64,
this matched a 4KB granule.
Note that the new default will prevent 4kB guest on 64kB host
because the granule will be set to 64kB which would be larger
than the guest page size. In that situation, the virtio-iommu
driver fails on viommu_domain_finalise() with
"granule 0x10000 larger than system page size 0x1000".
In that case the workaround is to request 4K granule.
The current limitation of global granule in the virtio-iommu
should be removed and turned into per domain granule. But
until we get this upgraded, this new default is probably
better because I don't think anyone is currently interested in
running a 4KB page size guest with virtio-iommu on a 64KB host.
However supporting 64kB guest on 64kB host with virtio-iommu and
VFIO looks a more important feature.
Signed-off-by: Eric Auger <eric.au...@redhat.com>
Reviewed-by: Philippe Mathieu-Daudé <phi...@linaro.org>
Reviewed-by: Zhenzhong Duan <zhenzhong.d...@intel.com>
Message-Id: <20240307134445.92296-4-eric.au...@redhat.com>
Reviewed-by: Michael S. Tsirkin <m...@redhat.com>
Signed-off-by: Michael S. Tsirkin <m...@redhat.com>
Commit: 695012903f99d42c03a5bc87fe24f591b6bf7153
https://github.com/qemu/qemu/commit/695012903f99d42c03a5bc87fe24f591b6bf7153
Author: Eric Auger <eric.au...@redhat.com>
Date: 2024-03-12 (Tue, 12 Mar 2024)
Changed paths:
M qemu-options.hx
Log Message:
-----------
qemu-options.hx: Document the virtio-iommu-pci granule option
We are missing an entry for the virtio-iommu-pci device. Add the
information on which machine it is currently supported and document
the new granule option.
Signed-off-by: Eric Auger <eric.au...@redhat.com>
Message-Id: <20240307134445.92296-5-eric.au...@redhat.com>
Reviewed-by: Michael S. Tsirkin <m...@redhat.com>
Signed-off-by: Michael S. Tsirkin <m...@redhat.com>
Reviewed-by: Philippe Mathieu-Daudé <phi...@linaro.org>
Commit: fdda908f945bcd985be4ebd2a06d00719bc15e93
https://github.com/qemu/qemu/commit/fdda908f945bcd985be4ebd2a06d00719bc15e93
Author: Eric Auger <eric.au...@redhat.com>
Date: 2024-03-12 (Tue, 12 Mar 2024)
Changed paths:
M hw/virtio/trace-events
Log Message:
-----------
virtio-iommu: Trace domain range limits as unsigned int
Use %u format to trace domain_range limits.
Signed-off-by: Eric Auger <eric.au...@redhat.com>
Reviewed-by: Zhenzhong Duan <zhenzhong.d...@intel.com>
Reviewed-by: Cédric Le Goater <c...@redhat.com>
Message-Id: <20240307134445.92296-6-eric.au...@redhat.com>
Reviewed-by: Michael S. Tsirkin <m...@redhat.com>
Signed-off-by: Michael S. Tsirkin <m...@redhat.com>
Commit: 01e7e4921ccebb81cebc69eb648040a57be4f5ff
https://github.com/qemu/qemu/commit/01e7e4921ccebb81cebc69eb648040a57be4f5ff
Author: Eric Auger <eric.au...@redhat.com>
Date: 2024-03-12 (Tue, 12 Mar 2024)
Changed paths:
M hw/virtio/virtio-iommu.c
M include/hw/virtio/virtio-iommu.h
Log Message:
-----------
virtio-iommu: Add an option to define the input range width
aw-bits is a new option that allows to set the bit width of
the input address range. This value will be used as a default for
the device config input_range.end. By default it is set to 64 bits
which is the current value.
Signed-off-by: Eric Auger <eric.au...@redhat.com>
Reviewed-by: Zhenzhong Duan <zhenzhong.d...@intel.com>
Reviewed-by: Cédric Le Goater <c...@redhat.com>
Message-Id: <20240307134445.92296-7-eric.au...@redhat.com>
Reviewed-by: Michael S. Tsirkin <m...@redhat.com>
Signed-off-by: Michael S. Tsirkin <m...@redhat.com>
Commit: 9b588be373ad01e7ce09e25f69f66b811af0b799
https://github.com/qemu/qemu/commit/9b588be373ad01e7ce09e25f69f66b811af0b799
Author: Eric Auger <eric.au...@redhat.com>
Date: 2024-03-12 (Tue, 12 Mar 2024)
Changed paths:
M hw/core/machine.c
M hw/i386/pc_q35.c
M tests/qtest/virtio-iommu-test.c
Log Message:
-----------
hw/i386/q35: Set virtio-iommu aw-bits default value to 39
Currently the default input range can extend to 64 bits. On x86,
when the virtio-iommu protects vfio devices, the physical iommu
may support only 39 bits. Let's set the default to 39, as done
for the intel-iommu.
We use hw_compat_8_2 to handle the compatibility for machines
before 9.0 which used to have a virtio-iommu default input range
of 64 bits.
Of course if aw-bits is set from the command line, the default
is overriden.
Signed-off-by: Eric Auger <eric.au...@redhat.com>
Message-Id: <20240307134445.92296-8-eric.au...@redhat.com>
Reviewed-by: Michael S. Tsirkin <m...@redhat.com>
Signed-off-by: Michael S. Tsirkin <m...@redhat.com>
Reviewed-by: Zhenzhong Duan <zhenzhong.d...@intel.com>
Commit: 62d776002c990d5b6fd4a2b6809ab2956c6e1ff0
https://github.com/qemu/qemu/commit/62d776002c990d5b6fd4a2b6809ab2956c6e1ff0
Author: Eric Auger <eric.au...@redhat.com>
Date: 2024-03-12 (Tue, 12 Mar 2024)
Changed paths:
M hw/arm/virt.c
Log Message:
-----------
hw/arm/virt: Set virtio-iommu aw-bits default value to 48
On ARM we set 48b as a default (matching SMMUv3 SMMU_IDR5.VAX == 0).
hw_compat_8_2 is used to handle the compatibility for machine types
before 9.0 (default was 64 bits).
Signed-off-by: Eric Auger <eric.au...@redhat.com>
Reviewed-by: Zhenzhong Duan <zhenzhong.d...@intel.com>
Message-Id: <20240307134445.92296-9-eric.au...@redhat.com>
Reviewed-by: Michael S. Tsirkin <m...@redhat.com>
Signed-off-by: Michael S. Tsirkin <m...@redhat.com>
Commit: f7ada75b3f7dd1369b10bac7f8297831c3a80967
https://github.com/qemu/qemu/commit/f7ada75b3f7dd1369b10bac7f8297831c3a80967
Author: Eric Auger <eric.au...@redhat.com>
Date: 2024-03-12 (Tue, 12 Mar 2024)
Changed paths:
M qemu-options.hx
Log Message:
-----------
qemu-options.hx: Document the virtio-iommu-pci aw-bits option
Document the new aw-bits option.
Signed-off-by: Eric Auger <eric.au...@redhat.com>
Message-Id: <20240307134445.92296-10-eric.au...@redhat.com>
Reviewed-by: Michael S. Tsirkin <m...@redhat.com>
Signed-off-by: Michael S. Tsirkin <m...@redhat.com>
Reviewed-by: Philippe Mathieu-Daudé <phi...@linaro.org>
Commit: 2eb6672cfdaea7dacd8e9bb0523887f13b9f85ce
https://github.com/qemu/qemu/commit/2eb6672cfdaea7dacd8e9bb0523887f13b9f85ce
Author: Jonathan Cameron <jonathan.came...@huawei.com>
Date: 2024-03-12 (Tue, 12 Mar 2024)
Changed paths:
M hw/acpi/hmat.c
Log Message:
-----------
hmat acpi: Do not add Memory Proximity Domain Attributes Structure targetting
non existent memory.
If qemu is started with a proximity node containing CPUs alone,
it will provide one of these structures to say memory in this
node is directly connected to itself.
This description is arguably pointless even if there is memory
in the node. If there is no memory present, and hence no SRAT
entry it breaks Linux HMAT passing and the table is rejected.
https://elixir.bootlin.com/linux/v6.7/source/drivers/acpi/numa/hmat.c#L444
Signed-off-by: Jonathan Cameron <jonathan.came...@huawei.com>
Message-Id: <20240307160326.31570-2-jonathan.came...@huawei.com>
Reviewed-by: Michael S. Tsirkin <m...@redhat.com>
Signed-off-by: Michael S. Tsirkin <m...@redhat.com>
Commit: 74e2845c5f95b0c139c79233ddb65bb17f2dd679
https://github.com/qemu/qemu/commit/74e2845c5f95b0c139c79233ddb65bb17f2dd679
Author: Jonathan Cameron <jonathan.came...@huawei.com>
Date: 2024-03-12 (Tue, 12 Mar 2024)
Changed paths:
M hw/acpi/hmat.c
Log Message:
-----------
hmat acpi: Fix out of bounds access due to missing use of indirection
With a numa set up such as
-numa nodeid=0,cpus=0 \
-numa nodeid=1,memdev=mem \
-numa nodeid=2,cpus=1
and appropriate hmat_lb entries the initiator list is correctly
computed and writen to HMAT as 0,2 but then the LB data is accessed
using the node id (here 2), landing outside the entry_list array.
Stash the reverse lookup when writing the initiator list and use
it to get the correct array index index.
Fixes: 4586a2cb83 ("hmat acpi: Build System Locality Latency and Bandwidth
Information Structure(s)")
Signed-off-by: Jonathan Cameron <jonathan.came...@huawei.com>
Message-Id: <20240307160326.31570-3-jonathan.came...@huawei.com>
Reviewed-by: Michael S. Tsirkin <m...@redhat.com>
Signed-off-by: Michael S. Tsirkin <m...@redhat.com>
Commit: bfc2f7a6caa6843e50019ee2511ad11cd5582711
https://github.com/qemu/qemu/commit/bfc2f7a6caa6843e50019ee2511ad11cd5582711
Author: Jonathan Cameron <jonathan.came...@huawei.com>
Date: 2024-03-12 (Tue, 12 Mar 2024)
Changed paths:
M include/hw/cxl/cxl_pci.h
Log Message:
-----------
hw/cxl: Fix missing reserved data in CXL Device DVSEC
The r3.1 specification introduced a new 2 byte field, but
to maintain DWORD alignment, a additional 2 reserved bytes
were added. Forgot those in updating the structure definition
but did include them in the size define leading to a buffer
overrun.
Also use the define so that we don't duplicate the value.
Fixes: Coverity ID 1534095 buffer overrun
Fixes: 8700ee15de ("hw/cxl: Standardize all references on CXL r3.1 and minor
updates")
Reported-by: Peter Maydell <peter.mayd...@linaro.org>
Signed-off-by: Jonathan Cameron <jonathan.came...@huawei.com>
Message-Id: <20240308143831.6256-1-jonathan.came...@huawei.com>
Reviewed-by: Michael S. Tsirkin <m...@redhat.com>
Signed-off-by: Michael S. Tsirkin <m...@redhat.com>
Commit: 73279cecca03f7c2b4489c5fea994e7349eaafaa
https://github.com/qemu/qemu/commit/73279cecca03f7c2b4489c5fea994e7349eaafaa
Author: Thomas Weißschuh <tho...@t-8ch.de>
Date: 2024-03-12 (Tue, 12 Mar 2024)
Changed paths:
M docs/specs/pvpanic.rst
Log Message:
-----------
docs/specs/pvpanic: document shutdown event
Shutdown requests are normally hardware dependent.
By extending pvpanic to also handle shutdown requests, guests can
submit such requests with an easily implementable and cross-platform
mechanism.
Signed-off-by: Thomas Weißschuh <tho...@t-8ch.de>
Message-Id: <20240310-pvpanic-shutdown-spec-v1-1-b258e182c...@t-8ch.de>
Reviewed-by: Michael S. Tsirkin <m...@redhat.com>
Signed-off-by: Michael S. Tsirkin <m...@redhat.com>
Commit: 578774c09a89dd1e3023677aad5ebb7a3562c8ba
https://github.com/qemu/qemu/commit/578774c09a89dd1e3023677aad5ebb7a3562c8ba
Author: Alex Bennée <alex.ben...@linaro.org>
Date: 2024-03-13 (Wed, 13 Mar 2024)
Changed paths:
M tests/vm/basevm.py
Log Message:
-----------
tests/vm: ensure we build everything by default
The "check" target by itself is not enough to ensure we build the user
mode binaries. While we can't test them with check-tcg we can at least
include them in the build.
Signed-off-by: Alex Bennée <alex.ben...@linaro.org>
Reviewed-by: Thomas Huth <th...@redhat.com>
Cc: Richard Henderson <richard.hender...@linaro.org>
Cc: Gustavo Romero <gustavo.rom...@linaro.org>
Commit: b6617e937e9abe6ce449729e2fdebf11014f7e49
https://github.com/qemu/qemu/commit/b6617e937e9abe6ce449729e2fdebf11014f7e49
Author: Gustavo Romero <gustavo.rom...@linaro.org>
Date: 2024-03-13 (Wed, 13 Mar 2024)
Changed paths:
M gdbstub/user.c
M include/gdbstub/user.h
M linux-user/main.c
M linux-user/signal.c
Log Message:
-----------
gdbstub: Rename back gdb_handlesig
Rename gdb_handlesig_reason back to gdb_handlesig. There is no need to
add a wrapper for gdb_handlesig and rename it when a new parameter is
added.
Signed-off-by: Gustavo Romero <gustavo.rom...@linaro.org>
Reviewed-by: Alex Bennée <alex.ben...@linaro.org>
Reviewed-by: Richard Henderson <richard.hender...@linaro.org>
Message-Id: <20240309030901.1726211-2-gustavo.rom...@linaro.org>
Signed-off-by: Alex Bennée <alex.ben...@linaro.org>
Commit: 4d6d8a05a0a6d102ca94e59a43804d65309921e3
https://github.com/qemu/qemu/commit/4d6d8a05a0a6d102ca94e59a43804d65309921e3
Author: Gustavo Romero <gustavo.rom...@linaro.org>
Date: 2024-03-13 (Wed, 13 Mar 2024)
Changed paths:
M linux-user/aarch64/signal.c
M linux-user/alpha/signal.c
M linux-user/arm/signal.c
M linux-user/hexagon/signal.c
M linux-user/hppa/signal.c
M linux-user/i386/signal.c
M linux-user/loongarch64/signal.c
M linux-user/m68k/signal.c
M linux-user/microblaze/signal.c
M linux-user/mips/signal.c
M linux-user/nios2/signal.c
M linux-user/openrisc/signal.c
M linux-user/ppc/signal.c
M linux-user/riscv/signal.c
M linux-user/s390x/signal.c
M linux-user/sh4/signal.c
M linux-user/signal-common.h
M linux-user/signal.c
M linux-user/sparc/signal.c
M linux-user/xtensa/signal.c
Log Message:
-----------
linux-user: Move tswap_siginfo out of target code
Move tswap_siginfo from target code to handle_pending_signal. This will
allow some cleanups and having the siginfo ready to be used in gdbstub.
Signed-off-by: Gustavo Romero <gustavo.rom...@linaro.org>
Suggested-by: Richard Henderson <richard.hender...@linaro.org>
Reviewed-by: Richard Henderson <richard.hender...@linaro.org>
Message-Id: <20240309030901.1726211-3-gustavo.rom...@linaro.org>
Signed-off-by: Alex Bennée <alex.ben...@linaro.org>
Commit: f84e313e0278222eb88b9ca29311f0df71abd001
https://github.com/qemu/qemu/commit/f84e313e0278222eb88b9ca29311f0df71abd001
Author: Gustavo Romero <gustavo.rom...@linaro.org>
Date: 2024-03-13 (Wed, 13 Mar 2024)
Changed paths:
M bsd-user/main.c
M bsd-user/signal.c
M gdbstub/user.c
M include/gdbstub/user.h
M linux-user/main.c
M linux-user/signal.c
Log Message:
-----------
gdbstub: Save target's siginfo
Save target's siginfo into gdbserver_state so it can be used later, for
example, in any stub that requires the target's si_signo and si_code.
This change affects only linux-user mode.
Signed-off-by: Gustavo Romero <gustavo.rom...@linaro.org>
Suggested-by: Richard Henderson <richard.hender...@linaro.org>
Message-Id: <20240309030901.1726211-4-gustavo.rom...@linaro.org>
Signed-off-by: Alex Bennée <alex.ben...@linaro.org>
Reviewed-by: Richard Henderson <richard.hender...@linaro.org>
Commit: 9ae5801d35b5228583dfcdb9c76cf2c6f4566215
https://github.com/qemu/qemu/commit/9ae5801d35b5228583dfcdb9c76cf2c6f4566215
Author: Gustavo Romero <gustavo.rom...@linaro.org>
Date: 2024-03-13 (Wed, 13 Mar 2024)
Changed paths:
M gdbstub/gdbstub.c
M gdbstub/internals.h
M gdbstub/user.c
Log Message:
-----------
gdbstub: Add Xfer:siginfo:read stub
Add stub to handle Xfer:siginfo:read packet query that requests the
machine's siginfo data.
This is used when GDB user executes 'print $_siginfo' and when the
machine stops due to a signal, for instance, on SIGSEGV. The information
in siginfo allows GDB to determiner further details on the signal, like
the fault address/insn when the SIGSEGV is caught.
Signed-off-by: Gustavo Romero <gustavo.rom...@linaro.org>
Message-Id: <20240309030901.1726211-5-gustavo.rom...@linaro.org>
Signed-off-by: Alex Bennée <alex.ben...@linaro.org>
Reviewed-by: Richard Henderson <richard.hender...@linaro.org>
Commit: bbc0543b1b8231eb9712aa9b93091a1ccb2a08cd
https://github.com/qemu/qemu/commit/bbc0543b1b8231eb9712aa9b93091a1ccb2a08cd
Author: Gustavo Romero <gustavo.rom...@linaro.org>
Date: 2024-03-13 (Wed, 13 Mar 2024)
Changed paths:
M tests/tcg/multiarch/Makefile.target
A tests/tcg/multiarch/gdbstub/test-qxfer-siginfo-read.py
A tests/tcg/multiarch/segfault.c
Log Message:
-----------
tests/tcg: Add multiarch test for Xfer:siginfo:read stub
Add multiarch test for testing if Xfer:siginfo:read query is properly
handled by gdbstub.
Signed-off-by: Gustavo Romero <gustavo.rom...@linaro.org>
Reviewed-by: Richard Henderson <richard.hender...@linaro.org>
Message-Id: <20240309030901.1726211-6-gustavo.rom...@linaro.org>
Signed-off-by: Alex Bennée <alex.ben...@linaro.org>
Commit: 6971998e241d8edc842b165b447f706c05166ae6
https://github.com/qemu/qemu/commit/6971998e241d8edc842b165b447f706c05166ae6
Author: Ilya Leoshkevich <i...@linux.ibm.com>
Date: 2024-03-13 (Wed, 13 Mar 2024)
Changed paths:
M gdbstub/user.c
Log Message:
-----------
gdbstub: Fix double close() of the follow-fork-mode socket
When the terminal GDB_FORK_ENABLED state is reached, the coordination
socket is not needed anymore and is therefore closed. However, if there
is a communication error between QEMU gdbstub and GDB, the generic
error handling code attempts to close it again.
Fix by closing it later - before returning - instead.
Fixes: Coverity CID 1539966
Fixes: d547e711a8a5 ("gdbstub: Implement follow-fork-mode child")
Signed-off-by: Ilya Leoshkevich <i...@linux.ibm.com>
Signed-off-by: Alex Bennée <alex.ben...@linaro.org>
Message-Id: <20240312001813.13720-1-...@linux.ibm.com>
Commit: 6fc69312313a2207a8fbc083658e0548746b707f
https://github.com/qemu/qemu/commit/6fc69312313a2207a8fbc083658e0548746b707f
Author: Peter Maydell <peter.mayd...@linaro.org>
Date: 2024-03-13 (Wed, 13 Mar 2024)
Changed paths:
M MAINTAINERS
M docs/interop/vhost-user.rst
M docs/specs/pvpanic.rst
M docs/system/device-emulation.rst
A docs/system/devices/vdpa-net.rst
A hw/acpi/acpi_generic_initiator.c
M hw/acpi/hmat.c
M hw/acpi/meson.build
M hw/arm/virt-acpi-build.c
M hw/arm/virt.c
M hw/audio/virtio-snd.c
M hw/core/machine.c
M hw/core/numa.c
M hw/core/qdev-properties-system.c
M hw/cxl/cxl-component-utils.c
M hw/i386/acpi-build.c
M hw/i386/pc.c
M hw/i386/pc_piix.c
M hw/i386/pc_q35.c
M hw/i386/pc_sysfw.c
M hw/net/igb.c
M hw/net/virtio-net.c
M hw/nvme/ctrl.c
M hw/pci-bridge/pci_expander_bridge.c
M hw/pci/pci.c
M hw/pci/pcie.c
M hw/pci/pcie_sriov.c
M hw/smbios/smbios.c
M hw/virtio/trace-events
M hw/virtio/vhost-user.c
M hw/virtio/vhost-vdpa.c
M hw/virtio/virtio-iommu.c
M hw/virtio/virtio-pci.c
M hw/virtio/virtio.c
A include/hw/acpi/acpi_generic_initiator.h
M include/hw/audio/virtio-snd.h
M include/hw/cxl/cxl_component.h
M include/hw/cxl/cxl_pci.h
M include/hw/firmware/smbios.h
M include/hw/i386/pc.h
M include/hw/pci/pcie_regs.h
M include/hw/pci/pcie_sriov.h
M include/hw/virtio/vhost-vdpa.h
M include/hw/virtio/virtio-iommu.h
M include/hw/virtio/virtio-pci.h
M include/hw/virtio/virtio.h
M include/standard-headers/linux/virtio_pci.h
M include/sysemu/numa.h
M net/trace-events
M net/vhost-vdpa.c
M qapi/common.json
M qapi/qom.json
M qemu-options.hx
M subprojects/libvhost-user/libvhost-user.c
M subprojects/libvhost-user/libvhost-user.h
M tests/qtest/virtio-iommu-test.c
Log Message:
-----------
Merge tag 'for_upstream' of https://git.kernel.org/pub/scm/virt/kvm/mst/qemu
into staging
virtio,pc,pci: features, cleanups, fixes
more memslots support in libvhost-user
support PCIe Gen5/Gen6 link speeds in pcie
more traces in vdpa
network simulation devices support in vdpa
SMBIOS type 9 descriptor implementation
Bump max_cpus to 4096 vcpus in q35
aw-bits and granule options in VIRTIO-IOMMU
Support report NUMA nodes for device memory using GI in acpi
Beginning of shutdown event support in pvpanic
fixes, cleanups all over the place.
Signed-off-by: Michael S. Tsirkin <m...@redhat.com>
# -----BEGIN PGP SIGNATURE-----
#
# iQFDBAABCAAtFiEEXQn9CHHI+FuUyooNKB8NuNKNVGkFAmXw0TMPHG1zdEByZWRo
# YXQuY29tAAoJECgfDbjSjVRp8x4H+gLMoGwaGAX7gDGPgn2Ix4j/3kO77ZJ9X9k/
# 1KqZu/9eMS1j2Ei+vZqf05w7qRjxxhwDq3ilEXF/+UFqgAehLqpRRB8j5inqvzYt
# +jv0DbL11PBp/oFjWcytm5CbiVsvq8KlqCF29VNzc162XdtcduUOWagL96y8lJfZ
# uPrOoyeR7SMH9lp3LLLHWgu+9W4nOS03RroZ6Umj40y5B7yR0Rrppz8lMw5AoQtr
# 0gMRnFhYXeiW6CXdz+Tzcr7XfvkkYDi/j7ibiNSURLBfOpZa6Y8+kJGKxz5H1K1G
# 6ZY4PBcOpQzl+NMrktPHogczgJgOK10t+1i/R3bGZYw2Qn/93Eg=
# =C0UU
# -----END PGP SIGNATURE-----
# gpg: Signature made Tue 12 Mar 2024 22:03:31 GMT
# gpg: using RSA key 5D09FD0871C8F85B94CA8A0D281F0DB8D28D5469
# gpg: issuer "m...@redhat.com"
# gpg: Good signature from "Michael S. Tsirkin <m...@kernel.org>" [full]
# gpg: aka "Michael S. Tsirkin <m...@redhat.com>" [full]
# Primary key fingerprint: 0270 606B 6F3C DF3D 0B17 0970 C350 3912 AFBE 8E67
# Subkey fingerprint: 5D09 FD08 71C8 F85B 94CA 8A0D 281F 0DB8 D28D 5469
* tag 'for_upstream' of https://git.kernel.org/pub/scm/virt/kvm/mst/qemu: (68
commits)
docs/specs/pvpanic: document shutdown event
hw/cxl: Fix missing reserved data in CXL Device DVSEC
hmat acpi: Fix out of bounds access due to missing use of indirection
hmat acpi: Do not add Memory Proximity Domain Attributes Structure targetting
non existent memory.
qemu-options.hx: Document the virtio-iommu-pci aw-bits option
hw/arm/virt: Set virtio-iommu aw-bits default value to 48
hw/i386/q35: Set virtio-iommu aw-bits default value to 39
virtio-iommu: Add an option to define the input range width
virtio-iommu: Trace domain range limits as unsigned int
qemu-options.hx: Document the virtio-iommu-pci granule option
virtio-iommu: Change the default granule to the host page size
virtio-iommu: Add a granule property
hw/i386/acpi-build: Add support for SRAT Generic Initiator structures
hw/acpi: Implement the SRAT GI affinity structure
qom: new object to associate device to NUMA node
hw/i386/pc: Inline pc_cmos_init() into pc_cmos_init_late() and remove it
hw/i386/pc: Set "normal" boot device order in pc_basic_device_init()
hw/i386/pc: Avoid one use of the current_machine global
hw/i386/pc: Remove "rtc_state" link again
Revert "hw/i386/pc: Confine system flash handling to pc_sysfw"
...
Signed-off-by: Peter Maydell <peter.mayd...@linaro.org>
# Conflicts:
# hw/core/machine.c
Commit: ba49d760eb04630e7b15f423ebecf6c871b8f77b
https://github.com/qemu/qemu/commit/ba49d760eb04630e7b15f423ebecf6c871b8f77b
Author: Peter Maydell <peter.mayd...@linaro.org>
Date: 2024-03-13 (Wed, 13 Mar 2024)
Changed paths:
M bsd-user/main.c
M bsd-user/signal.c
M gdbstub/gdbstub.c
M gdbstub/internals.h
M gdbstub/user.c
M include/gdbstub/user.h
M linux-user/aarch64/signal.c
M linux-user/alpha/signal.c
M linux-user/arm/signal.c
M linux-user/hexagon/signal.c
M linux-user/hppa/signal.c
M linux-user/i386/signal.c
M linux-user/loongarch64/signal.c
M linux-user/m68k/signal.c
M linux-user/main.c
M linux-user/microblaze/signal.c
M linux-user/mips/signal.c
M linux-user/nios2/signal.c
M linux-user/openrisc/signal.c
M linux-user/ppc/signal.c
M linux-user/riscv/signal.c
M linux-user/s390x/signal.c
M linux-user/sh4/signal.c
M linux-user/signal-common.h
M linux-user/signal.c
M linux-user/sparc/signal.c
M linux-user/xtensa/signal.c
M tests/tcg/multiarch/Makefile.target
A tests/tcg/multiarch/gdbstub/test-qxfer-siginfo-read.py
A tests/tcg/multiarch/segfault.c
M tests/vm/basevm.py
Log Message:
-----------
Merge tag 'pull-maintainer-final-130324-1' of https://gitlab.com/stsquad/qemu
into staging
final updates for 9.0 (testing, gdbstub):
- fix the over rebuilding of test VMs
- support Xfer:siginfo:read in gdbstub
- fix double close() in gdbstub
# -----BEGIN PGP SIGNATURE-----
#
# iQEzBAABCgAdFiEEZoWumedRZ7yvyN81+9DbCVqeKkQFAmXxkb0ACgkQ+9DbCVqe
# KkSw9wf+K+3kJYaZ2unEFku3Y6f4Z9XkrZCsFQFVNIJQgpYVc6peQyLUB1pZwzZc
# yoQhmTIgej16iRZc7gEcJhFl2zlX2vulE/m+wiaR0Chv3E2r510AGn4aWl+GLB9+
# /WduHaz1NobPW4JWaarxespa84Re8QZQgqkHX4nwYd++FW63E4uxydL4F1nmSNca
# eTA6RwS48h4wqPzHBX72hYTRUnYrDUSSGCGUDzK3NHumuPi+AQ77GLRMO0MTYFfy
# hWriapogCmghY+Xtn++eUIwDyh1CCnUT6Ntf5Qj06bZ+f6eaTwINM8QWhj9mxYX+
# 5/F5Q4JJDqRPYw/hF4wYXRsiZxTYFw==
# =BOWW
# -----END PGP SIGNATURE-----
# gpg: Signature made Wed 13 Mar 2024 11:45:01 GMT
# gpg: using RSA key 6685AE99E75167BCAFC8DF35FBD0DB095A9E2A44
# gpg: Good signature from "Alex Bennée (Master Work Key)
<alex.ben...@linaro.org>" [full]
# Primary key fingerprint: 6685 AE99 E751 67BC AFC8 DF35 FBD0 DB09 5A9E 2A44
* tag 'pull-maintainer-final-130324-1' of https://gitlab.com/stsquad/qemu:
gdbstub: Fix double close() of the follow-fork-mode socket
tests/tcg: Add multiarch test for Xfer:siginfo:read stub
gdbstub: Add Xfer:siginfo:read stub
gdbstub: Save target's siginfo
linux-user: Move tswap_siginfo out of target code
gdbstub: Rename back gdb_handlesig
tests/vm: ensure we build everything by default
Signed-off-by: Peter Maydell <peter.mayd...@linaro.org>
Compare: https://github.com/qemu/qemu/compare/51e31f214071...ba49d760eb04
To unsubscribe from these emails, change your notification settings at
https://github.com/qemu/qemu/settings/notifications
