summary refs log tree commit diff stats
path: root/python/qemu/utils/qemu_ga_client.py (unfollow)
Commit message (Collapse)AuthorFilesLines
2025-06-26vfio-user: add coalesced posted writesJohn Levon5-0/+158
Add new message to send multiple writes to server in a single message. Prevents the outgoing queue from overflowing when a long latency operation is followed by a series of posted writes. Originally-by: John Johnson <john.g.johnson@oracle.com> Signed-off-by: Elena Ufimtseva <elena.ufimtseva@oracle.com> Signed-off-by: Jagannathan Raman <jag.raman@oracle.com> Signed-off-by: John Levon <john.levon@nutanix.com> Reviewed-by: Cédric Le Goater <clg@redhat.com> Link: https://lore.kernel.org/qemu-devel/20250625193012.2316242-18-john.levon@nutanix.com Signed-off-by: Cédric Le Goater <clg@redhat.com>
2025-06-26vfio-user: support posted writesJohn Levon4-6/+63
Support an asynchronous send of a vfio-user socket message (no wait for a reply) when the write is posted. This is only safe when no regions are mappable by the VM. Add an option to explicitly disable this as well. Signed-off-by: John Levon <john.levon@nutanix.com> Reviewed-by: Cédric Le Goater <clg@redhat.com> Link: https://lore.kernel.org/qemu-devel/20250625193012.2316242-17-john.levon@nutanix.com Signed-off-by: Cédric Le Goater <clg@redhat.com>
2025-06-26vfio-user: add 'x-msg-timeout' optionJohn Levon3-3/+10
By default, the vfio-user subsystem will wait 5 seconds for a message reply from the server. Add an option to allow this to be configurable. Originally-by: John Johnson <john.g.johnson@oracle.com> Signed-off-by: Elena Ufimtseva <elena.ufimtseva@oracle.com> Signed-off-by: Jagannathan Raman <jag.raman@oracle.com> Signed-off-by: John Levon <john.levon@nutanix.com> Reviewed-by: Cédric Le Goater <clg@redhat.com> Link: https://lore.kernel.org/qemu-devel/20250625193012.2316242-16-john.levon@nutanix.com Signed-off-by: Cédric Le Goater <clg@redhat.com>
2025-06-26vfio-user: implement VFIO_USER_DMA_READ/WRITEJohn Levon4-1/+223
Unlike most other messages, this is a server->client message, for when a server wants to do "DMA"; this is slow, so normally the server has memory directly mapped instead. Originally-by: John Johnson <john.g.johnson@oracle.com> Signed-off-by: Elena Ufimtseva <elena.ufimtseva@oracle.com> Signed-off-by: Jagannathan Raman <jag.raman@oracle.com> Signed-off-by: John Levon <john.levon@nutanix.com> Reviewed-by: Cédric Le Goater <clg@redhat.com> Link: https://lore.kernel.org/qemu-devel/20250625193012.2316242-15-john.levon@nutanix.com Signed-off-by: Cédric Le Goater <clg@redhat.com>
2025-06-26vfio-user: implement VFIO_USER_DMA_MAP/UNMAPJohn Levon5-4/+257
When the vfio-user container gets mapping updates, share them with the vfio-user by sending a message; this can include the region fd, allowing the server to directly mmap() the region as needed. For performance, we only wait for the message responses when we're doing with a series of updates via the listener_commit() callback. Originally-by: John Johnson <john.g.johnson@oracle.com> Signed-off-by: Jagannathan Raman <jag.raman@oracle.com> Signed-off-by: Elena Ufimtseva <elena.ufimtseva@oracle.com> Signed-off-by: John Levon <john.levon@nutanix.com> Reviewed-by: Cédric Le Goater <clg@redhat.com> Link: https://lore.kernel.org/qemu-devel/20250625193012.2316242-14-john.levon@nutanix.com Signed-off-by: Cédric Le Goater <clg@redhat.com>
2025-06-26vfio-user: implement VFIO_USER_DEVICE_RESETJohn Levon3-0/+35
Hook this call up to the legacy reset handler for vfio-user-pci. Originally-by: John Johnson <john.g.johnson@oracle.com> Signed-off-by: Elena Ufimtseva <elena.ufimtseva@oracle.com> Signed-off-by: Jagannathan Raman <jag.raman@oracle.com> Signed-off-by: John Levon <john.levon@nutanix.com> Reviewed-by: Cédric Le Goater <clg@redhat.com> Link: https://lore.kernel.org/qemu-devel/20250625193012.2316242-13-john.levon@nutanix.com Signed-off-by: Cédric Le Goater <clg@redhat.com>
2025-06-26vfio-user: set up container access to the proxyJohn Levon2-9/+36
The user container will shortly need access to the underlying vfio-user proxy; set this up. Originally-by: John Johnson <john.g.johnson@oracle.com> Signed-off-by: Elena Ufimtseva <elena.ufimtseva@oracle.com> Signed-off-by: Jagannathan Raman <jag.raman@oracle.com> Signed-off-by: John Levon <john.levon@nutanix.com> Reviewed-by: Cédric Le Goater <clg@redhat.com> Link: https://lore.kernel.org/qemu-devel/20250625193012.2316242-12-john.levon@nutanix.com Signed-off-by: Cédric Le Goater <clg@redhat.com>
2025-06-26vfio-user: forward MSI-X PBA BAR accesses to serverJohn Levon2-0/+65
For vfio-user, the server holds the pending IRQ state; set up an I/O region for the MSI-X PBA so we can ask the server for this state on a PBA read. Originally-by: John Johnson <john.g.johnson@oracle.com> Signed-off-by: Elena Ufimtseva <elena.ufimtseva@oracle.com> Signed-off-by: Jagannathan Raman <jag.raman@oracle.com> Signed-off-by: John Levon <john.levon@nutanix.com> Reviewed-by: Cédric Le Goater <clg@redhat.com> Link: https://lore.kernel.org/qemu-devel/20250625193012.2316242-11-john.levon@nutanix.com Signed-off-by: Cédric Le Goater <clg@redhat.com>
2025-06-26vfio-user: implement VFIO_USER_DEVICE_GET/SET_IRQ*John Levon3-0/+165
IRQ setup uses the same semantics as the traditional vfio path, but we need to share the corresponding file descriptors with the server as necessary. Originally-by: John Johnson <john.g.johnson@oracle.com> Signed-off-by: Elena Ufimtseva <elena.ufimtseva@oracle.com> Signed-off-by: Jagannathan Raman <jag.raman@oracle.com> Signed-off-by: John Levon <john.levon@nutanix.com> Reviewed-by: Cédric Le Goater <clg@redhat.com> Link: https://lore.kernel.org/qemu-devel/20250625193012.2316242-10-john.levon@nutanix.com Signed-off-by: Cédric Le Goater <clg@redhat.com>
2025-06-26vfio-user: set up PCI in vfio_user_pci_realize()John Levon1-0/+29
Re-use PCI setup functions from hw/vfio/pci.c to realize the vfio-user PCI device. Originally-by: John Johnson <john.g.johnson@oracle.com> Signed-off-by: Elena Ufimtseva <elena.ufimtseva@oracle.com> Signed-off-by: Jagannathan Raman <jag.raman@oracle.com> Signed-off-by: John Levon <john.levon@nutanix.com> Reviewed-by: Cédric Le Goater <clg@redhat.com> Link: https://lore.kernel.org/qemu-devel/20250625193012.2316242-9-john.levon@nutanix.com Signed-off-by: Cédric Le Goater <clg@redhat.com>
2025-06-26vfio-user: implement VFIO_USER_REGION_READ/WRITEJohn Levon3-0/+92
Originally-by: John Johnson <john.g.johnson@oracle.com> Signed-off-by: Elena Ufimtseva <elena.ufimtseva@oracle.com> Signed-off-by: Jagannathan Raman <jag.raman@oracle.com> Signed-off-by: John Levon <john.levon@nutanix.com> Reviewed-by: Cédric Le Goater <clg@redhat.com> Link: https://lore.kernel.org/qemu-devel/20250625193012.2316242-8-john.levon@nutanix.com Signed-off-by: Cédric Le Goater <clg@redhat.com>
2025-06-26vfio-user: implement VFIO_USER_DEVICE_GET_REGION_INFOJohn Levon6-0/+103
Add support for getting region info for vfio-user. As vfio-user has one fd per region, enable ->use_region_fds. Originally-by: John Johnson <john.g.johnson@oracle.com> Signed-off-by: Elena Ufimtseva <elena.ufimtseva@oracle.com> Signed-off-by: Jagannathan Raman <jag.raman@oracle.com> Signed-off-by: John Levon <john.levon@nutanix.com> Reviewed-by: Cédric Le Goater <clg@redhat.com> Link: https://lore.kernel.org/qemu-devel/20250625193012.2316242-7-john.levon@nutanix.com Signed-off-by: Cédric Le Goater <clg@redhat.com>
2025-06-26vfio-user: implement VFIO_USER_DEVICE_GET_INFOJohn Levon8-7/+107
Add support for getting basic device information. Originally-by: John Johnson <john.g.johnson@oracle.com> Signed-off-by: Elena Ufimtseva <elena.ufimtseva@oracle.com> Signed-off-by: Jagannathan Raman <jag.raman@oracle.com> Signed-off-by: John Levon <john.levon@nutanix.com> Reviewed-by: Cédric Le Goater <clg@redhat.com> Link: https://lore.kernel.org/qemu-devel/20250625193012.2316242-6-john.levon@nutanix.com Signed-off-by: Cédric Le Goater <clg@redhat.com>
2025-06-26vfio-user: implement message send infrastructureJohn Levon5-2/+606
Add plumbing for sending vfio-user messages on the control socket. Add initial version negotation on connection. Originally-by: John Johnson <john.g.johnson@oracle.com> Signed-off-by: Jagannathan Raman <jag.raman@oracle.com> Signed-off-by: Elena Ufimtseva <elena.ufimtseva@oracle.com> Signed-off-by: John Levon <john.levon@nutanix.com> Reviewed-by: Cédric Le Goater <clg@redhat.com> Link: https://lore.kernel.org/qemu-devel/20250625193012.2316242-5-john.levon@nutanix.com Signed-off-by: Cédric Le Goater <clg@redhat.com>
2025-06-26vfio-user: implement message receive infrastructureJohn Levon7-0/+499
Add the basic implementation for receiving vfio-user messages from the control socket. Originally-by: John Johnson <john.g.johnson@oracle.com> Signed-off-by: Elena Ufimtseva <elena.ufimtseva@oracle.com> Signed-off-by: Jagannathan Raman <jag.raman@oracle.com> Signed-off-by: John Levon <john.levon@nutanix.com> Reviewed-by: Cédric Le Goater <clg@redhat.com> Link: https://lore.kernel.org/qemu-devel/20250625193012.2316242-4-john.levon@nutanix.com Signed-off-by: Cédric Le Goater <clg@redhat.com>
2025-06-26vfio-user: connect vfio proxy to remote serverJohn Levon5-0/+266
Introduce the vfio-user "proxy": this is the client code responsible for sending and receiving vfio-user messages across the control socket. The new files hw/vfio-user/proxy.[ch] contain some basic plumbing for managing the proxy; initialize the proxy during realization of the VFIOUserPCIDevice instance. Originally-by: John Johnson <john.g.johnson@oracle.com> Signed-off-by: Elena Ufimtseva <elena.ufimtseva@oracle.com> Signed-off-by: Jagannathan Raman <jag.raman@oracle.com> Signed-off-by: John Levon <john.levon@nutanix.com> Reviewed-by: Cédric Le Goater <clg@redhat.com> Link: https://lore.kernel.org/qemu-devel/20250625193012.2316242-3-john.levon@nutanix.com Signed-off-by: Cédric Le Goater <clg@redhat.com>
2025-06-26vfio-user: add vfio-user class and containerJohn Levon9-0/+441
Introduce basic plumbing for vfio-user with CONFIG_VFIO_USER. We introduce VFIOUserContainer in hw/vfio-user/container.c, which is a container type for the "IOMMU" type "vfio-iommu-user", and share some common container code from hw/vfio/container.c. Add hw/vfio-user/pci.c for instantiating VFIOUserPCIDevice objects, sharing some common code from hw/vfio/pci.c. Originally-by: John Johnson <john.g.johnson@oracle.com> Signed-off-by: Elena Ufimtseva <elena.ufimtseva@oracle.com> Signed-off-by: Jagannathan Raman <jag.raman@oracle.com> Signed-off-by: John Levon <john.levon@nutanix.com> Reviewed-by: Cédric Le Goater <clg@redhat.com> Link: https://lore.kernel.org/qemu-devel/20250625193012.2316242-2-john.levon@nutanix.com Signed-off-by: Cédric Le Goater <clg@redhat.com>
2025-06-26vfio/container: fails mdev hotplug if add migration blocker failedZhenzhong Duan1-2/+6
It's aggressive to abort a running QEMU process when hotplug a mdev and it fails migration blocker adding. Fix by just failing mdev hotplug itself. Signed-off-by: Zhenzhong Duan <zhenzhong.duan@intel.com> Reviewed-by: Cédric Le Goater <clg@redhat.com> Link: https://lore.kernel.org/qemu-devel/20250623102235.94877-3-zhenzhong.duan@intel.com [ clg: Changed test on value returned by migrate_add_blocker_modes() ] Signed-off-by: Cédric Le Goater <clg@redhat.com>
2025-06-26vfio/container: Fix SIGSEGV when open container file failsZhenzhong Duan1-1/+3
When open /dev/vfio/vfio fails, SIGSEGV triggers because vfio_listener_unregister() doesn't support a NULL bcontainer pointer. Fixes: a1f267a7d4d9 ("vfio/container: reform vfio_container_connect cleanup") Signed-off-by: Zhenzhong Duan <zhenzhong.duan@intel.com> Reviewed-by: Cédric Le Goater <clg@redhat.com> Link: https://lore.kernel.org/qemu-devel/20250623102235.94877-2-zhenzhong.duan@intel.com Signed-off-by: Cédric Le Goater <clg@redhat.com>
2025-06-26vfio: add license tag to some filesJohn Levon4-0/+9
Add SPDX-License-Identifier to some files missing it in hw/vfio/. Signed-off-by: John Levon <john.levon@nutanix.com> Reviewed-by: Daniel P. Berrangé <berrange@redhat.com> Link: https://lore.kernel.org/qemu-devel/20250623093053.1495509-1-john.levon@nutanix.com Signed-off-by: Cédric Le Goater <clg@redhat.com>
2025-06-26vfio: add documentation for posted write argumentJohn Levon1-0/+1
Signed-off-by: John Levon <john.levon@nutanix.com> Reviewed-by: Cédric Le Goater <clg@redhat.com> Link: https://lore.kernel.org/qemu-devel/20250616101314.3189793-1-john.levon@nutanix.com Signed-off-by: Cédric Le Goater <clg@redhat.com>
2025-06-26vfio: add vfio_device_get_region_fd()John Levon3-4/+20
This keeps the existence of ->region_fds private to hw/vfio/device.c. Signed-off-by: John Levon <john.levon@nutanix.com> Reviewed-by: Cédric Le Goater <clg@redhat.com> Reviewed-by: Philippe Mathieu-Daudé <philmd@linaro.org> Link: https://lore.kernel.org/qemu-devel/20250616101337.3190027-1-john.levon@nutanix.com Signed-off-by: Cédric Le Goater <clg@redhat.com>
2025-06-26hw/vfio/ap: attribute constructor for cfg_chg_events_lockRorie Reyes1-7/+5
Created an attribute constructor for cfg_chg_events_lock for locking mechanism when storing event information for an AP configuration change event Fixes: fd03360215 ("Storing event information for an AP configuration change event") Signed-off-by: Rorie Reyes <rreyes@linux.ibm.com> Reviewed-by: Thomas Huth <thuth@redhat.com> Link: https://lore.kernel.org/qemu-devel/20250611211252.82107-1-rreyes@linux.ibm.com Signed-off-by: Cédric Le Goater <clg@redhat.com>
2025-06-24docs: define policy forbidding use of AI code generatorsDaniel P. Berrangé1-1/+54
There has been an explosion of interest in so called AI code generators. Thus far though, this is has not been matched by a broadly accepted legal interpretation of the licensing implications for code generator outputs. While the vendors may claim there is no problem and a free choice of license is possible, they have an inherent conflict of interest in promoting this interpretation. More broadly there is, as yet, no broad consensus on the licensing implications of code generators trained on inputs under a wide variety of licenses The DCO requires contributors to assert they have the right to contribute under the designated project license. Given the lack of consensus on the licensing of AI code generator output, it is not considered credible to assert compliance with the DCO clause (b) or (c) where a patch includes such generated code. This patch thus defines a policy that the QEMU project will currently not accept contributions where use of AI code generators is either known, or suspected. These are early days of AI-assisted software development. The legal questions will be resolved eventually. The tools will mature, and we can expect some to become safely usable in free software projects. The policy we set now must be for today, and be open to revision. It's best to start strict and safe, then relax. Meanwhile requests for exceptions can also be considered on a case by case basis. Signed-off-by: Daniel P. Berrangé <berrange@redhat.com> Reviewed-by: Kevin Wolf <kwolf@redhat.com> Reviewed-by: Stefan Hajnoczi <stefanha@redhat.com> Reviewed-by: Alex Bennée <alex.bennee@linaro.org> Signed-off-by: Markus Armbruster <armbru@redhat.com> Signed-off-by: Stefan Hajnoczi <stefanha@redhat.com>
2025-06-24docs: define policy limiting the inclusion of generated filesDaniel P. Berrangé1-0/+55
Files contributed to QEMU are generally expected to be provided in the preferred format for manipulation. IOW, we generally don't expect to have generated / compiled code included in the tree, rather, we expect to run the code generator / compiler as part of the build process. There are some obvious exceptions to this seen in our existing tree, the biggest one being the inclusion of many binary firmware ROMs. A more niche example is the inclusion of a generated eBPF program. Or the CI dockerfiles which are mostly auto-generated. In these cases, however, the preferred format source code is still required to be included, alongside the generated output. Tools which perform user defined algorithmic transformations on code are not considered to be "code generators". ie, we permit use of coccinelle, spell checkers, and sed/awk/etc to manipulate code. Such use of automated manipulation should still be declared in the commit message. One off generators which create a boilerplate file which the author then fills in, are acceptable if their output has clear copyright and license status. This could be where a contributor writes a throwaway python script to automate creation of some mundane piece of code for example. Signed-off-by: Daniel P. Berrangé <berrange@redhat.com> Reviewed-by: Alex Bennée <alex.bennee@linaro.org> Reviewed-by: Stefan Hajnoczi <stefanha@redhat.com> Signed-off-by: Markus Armbruster <armbru@redhat.com> Signed-off-by: Stefan Hajnoczi <stefanha@redhat.com>
2025-06-24docs: introduce dedicated page about code provenance / sign-offDaniel P. Berrangé3-22/+234
Currently we have a short paragraph saying that patches must include a Signed-off-by line, and merely link to the kernel documentation. The linked kernel docs have a lot of content beyond the part about sign-off an thus are misleading/distracting to QEMU contributors. This introduces a dedicated 'code-provenance' page in QEMU talking about why we require sign-off, explaining the other tags we commonly use, and what to do in some edge cases. Signed-off-by: Daniel P. Berrangé <berrange@redhat.com> Reviewed-by: Peter Maydell <peter.maydell@linaro.org> Reviewed-by: Stefan Hajnoczi <stefanha@redhat.com> Reviewed-by: Alex Bennée <alex.bennee@linaro.org> Signed-off-by: Markus Armbruster <armbru@redhat.com> Signed-off-by: Stefan Hajnoczi <stefanha@redhat.com>
2025-06-23physmem: Support coordinated discarding of RAM with guest_memfdChenyi Qiang3-2/+31
A new field, attributes, was introduced in RAMBlock to link to a RamBlockAttributes object, which centralizes all guest_memfd related information (such as fd and status bitmap) within a RAMBlock. Create and initialize the RamBlockAttributes object upon ram_block_add(). Meanwhile, register the object in the target RAMBlock's MemoryRegion. After that, guest_memfd-backed RAMBlock is associated with the RamDiscardManager interface, and the users can execute RamDiscardManager specific handling. For example, VFIO will register the RamDiscardListener and get notifications when the state_change() helper invokes. As coordinate discarding of RAM with guest_memfd is now supported, only block uncoordinated discard. Tested-by: Alexey Kardashevskiy <aik@amd.com> Reviewed-by: Alexey Kardashevskiy <aik@amd.com> Acked-by: David Hildenbrand <david@redhat.com> Signed-off-by: Chenyi Qiang <chenyi.qiang@intel.com> Link: https://lore.kernel.org/r/20250612082747.51539-6-chenyi.qiang@intel.com Signed-off-by: Peter Xu <peterx@redhat.com>
2025-06-23ram-block-attributes: Introduce RamBlockAttributes to manage RAMBlock with ↵Chenyi Qiang5-0/+470
guest_memfd Commit 852f0048f3 ("RAMBlock: make guest_memfd require uncoordinated discard") highlighted that subsystems like VFIO may disable RAM block discard. However, guest_memfd relies on discard operations for page conversion between private and shared memory, potentially leading to the stale IOMMU mapping issue when assigning hardware devices to confidential VMs via shared memory. To address this and allow shared device assignement, it is crucial to ensure the VFIO system refreshes its IOMMU mappings. RamDiscardManager is an existing interface (used by virtio-mem) to adjust VFIO mappings in relation to VM page assignment. Effectively page conversion is similar to hot-removing a page in one mode and adding it back in the other. Therefore, similar actions are required for page conversion events. Introduce the RamDiscardManager to guest_memfd to facilitate this process. Since guest_memfd is not an object, it cannot directly implement the RamDiscardManager interface. Implementing it in HostMemoryBackend is not appropriate because guest_memfd is per RAMBlock, and some RAMBlocks have a memory backend while others do not. Notably, virtual BIOS RAMBlocks using memory_region_init_ram_guest_memfd() do not have a backend. To manage RAMBlocks with guest_memfd, define a new object named RamBlockAttributes to implement the RamDiscardManager interface. This object can store the guest_memfd information such as the bitmap for shared memory and the registered listeners for event notifications. A new state_change() helper function is provided to notify listeners, such as VFIO, allowing VFIO to do dynamically DMA map and unmap for the shared memory according to conversion events. Note that in the current context of RamDiscardManager for guest_memfd, the shared state is analogous to being populated, while the private state can be considered discarded for simplicity. In the future, it would be more complicated if considering more states like private/shared/discarded at the same time. In current implementation, memory state tracking is performed at the host page size granularity, as the minimum conversion size can be one page per request. Additionally, VFIO expected the DMA mapping for a specific IOVA to be mapped and unmapped with the same granularity. Confidential VMs may perform partial conversions, such as conversions on small regions within a larger one. To prevent such invalid cases and until support for DMA mapping cut operations is available, all operations are performed with 4K granularity. In addition, memory conversion failures cause QEMU to quit rather than resuming the guest or retrying the operation at present. It would be future work to add more error handling or rollback mechanisms once conversion failures are allowed. For example, in-place conversion of guest_memfd could retry the unmap operation during the conversion from shared to private. For now, keep the complex error handling out of the picture as it is not required. Tested-by: Alexey Kardashevskiy <aik@amd.com> Reviewed-by: Alexey Kardashevskiy <aik@amd.com> Reviewed-by: Pankaj Gupta <pankaj.gupta@amd.com> Signed-off-by: Chenyi Qiang <chenyi.qiang@intel.com> Link: https://lore.kernel.org/r/20250612082747.51539-5-chenyi.qiang@intel.com [peterx: squash fixup from Chenyi to fix builds] Signed-off-by: Peter Xu <peterx@redhat.com>
2025-06-23memory: Unify the definiton of ReplayRamPopulate() and ReplayRamDiscard()Chenyi Qiang4-36/+76
Update ReplayRamDiscard() function to return the result and unify the ReplayRamPopulate() and ReplayRamDiscard() to ReplayRamDiscardState() at the same time due to their identical definitions. This unification simplifies related structures, such as VirtIOMEMReplayData, which makes it cleaner. Reviewed-by: David Hildenbrand <david@redhat.com> Reviewed-by: Pankaj Gupta <pankaj.gupta@amd.com> Reviewed-by: Xiaoyao Li <xiaoyao.li@intel.com> Signed-off-by: Chenyi Qiang <chenyi.qiang@intel.com> Link: https://lore.kernel.org/r/20250612082747.51539-4-chenyi.qiang@intel.com Signed-off-by: Peter Xu <peterx@redhat.com>
2025-06-23memory: Change memory_region_set_ram_discard_manager() to return the resultChenyi Qiang3-19/+27
Modify memory_region_set_ram_discard_manager() to return -EBUSY if a RamDiscardManager is already set in the MemoryRegion. The caller must handle this failure, such as having virtio-mem undo its actions and fail the realize() process. Opportunistically move the call earlier to avoid complex error handling. This change is beneficial when introducing a new RamDiscardManager instance besides virtio-mem. After ram_block_coordinated_discard_require(true) unlocks all RamDiscardManager instances, only one instance is allowed to be set for one MemoryRegion at present. Suggested-by: David Hildenbrand <david@redhat.com> Reviewed-by: David Hildenbrand <david@redhat.com> Reviewed-by: Pankaj Gupta <pankaj.gupta@amd.com> Tested-by: Alexey Kardashevskiy <aik@amd.com> Reviewed-by: Alexey Kardashevskiy <aik@amd.com> Reviewed-by: Xiaoyao Li <xiaoyao.li@intel.com> Signed-off-by: Chenyi Qiang <chenyi.qiang@intel.com> Link: https://lore.kernel.org/r/20250612082747.51539-3-chenyi.qiang@intel.com Signed-off-by: Peter Xu <peterx@redhat.com>
2025-06-23memory: Export a helper to get intersection of a MemoryRegionSection with a ↵Chenyi Qiang2-27/+35
given range Rename the helper to memory_region_section_intersect_range() to make it more generic. Meanwhile, define the @end as Int128 and replace the related operations with Int128_* format since the helper is exported as a wider API. Suggested-by: Alexey Kardashevskiy <aik@amd.com> Reviewed-by: Alexey Kardashevskiy <aik@amd.com> Reviewed-by: Pankaj Gupta <pankaj.gupta@amd.com> Reviewed-by: David Hildenbrand <david@redhat.com> Reviewed-by: Zhao Liu <zhao1.liu@intel.com> Reviewed-by: Xiaoyao Li <xiaoyao.li@intel.com> Signed-off-by: Chenyi Qiang <chenyi.qiang@intel.com> Link: https://lore.kernel.org/r/20250612082747.51539-2-chenyi.qiang@intel.com Signed-off-by: Peter Xu <peterx@redhat.com>
2025-06-23migration: Don't sync volatile memory after migration completesChaney, Ben1-1/+3
Syncing volatile memory provides no benefit, instead it can cause performance issues in some cases. Only sync memory that is marked as non-volatile after migration completes on destination. Signed-off-by: Ben Chaney <bchaney@akamai.com> Fixes: bd108a44bc29 (migration: ram: Switch to ram block writeback) Link: https://lore.kernel.org/r/1CC43F59-336F-4A12-84AD-DB89E0A17A95@akamai.com Signed-off-by: Peter Xu <peterx@redhat.com>
2025-06-23tests/migration: Setup pre-listened cpr.sock to remove race-condition.Jaehoon Kim1-2/+12
When the source VM attempts to connect to the destination VM's Unix domain socket (cpr.sock) during a cpr-transfer test, race conditions can occur if the socket file isn't ready. This can lead to connection failures when running tests. This patch creates and listens on the socket in advance, and passes the pre-listened FD directly. This avoids timing issues and improves the reliability of CPR tests. Reviewed-by: Jason J. Herne <jjherne@linux.ibm.com> Signed-off-by: Jaehoon Kim <jhkim@linux.ibm.com> Reviewed-by: Steve Sistare <steven.sistare@oracle.com> Link: https://lore.kernel.org/r/20250611205610.147008-2-jhkim@linux.ibm.com [peterx: null-initialize opts_target, per Steve] Signed-off-by: Peter Xu <peterx@redhat.com>
2025-06-23migration: Support fd-based socket address in cpr_transfer_inputJaehoon Kim1-2/+5
Extend cpr_transfer_input to handle SOCKET_ADDRESS_TYPE_FD alongside SOCKET_ADDRESS_TYPE_UNIX. This change supports the use of pre-listened socket file descriptors for cpr migration channels. This change is particularly useful in qtest environments, where the socket may be created externally and passed via fd. Reviewed-by: Jason J. Herne <jjherne@linux.ibm.com> Reviewed-by: Steve Sistare <steven.sistare@oracle.com> Signed-off-by: Jaehoon Kim <jhkim@linux.ibm.com> Link: https://lore.kernel.org/r/20250611205610.147008-3-jhkim@linux.ibm.com Signed-off-by: Peter Xu <peterx@redhat.com>
2025-06-23ui/vnc: Update display update interval when VM state changes to RUNNINGJuraj Marcin2-0/+14
If a virtual machine is paused for an extended period time, for example, due to an incoming migration, there are also no changes on the screen. VNC in such case increases the display update interval by VNC_REFRESH_INTERVAL_INC (50 ms). The update interval can then grow up to VNC_REFRESH_INTERVAL_MAX (3000 ms). When the machine resumes, it can then take up to 3 seconds for the first display update. Furthermore, the update interval is then halved with each display update with changes on the screen. If there are moving elements on the screen, such as a video, this can be perceived as freezing and stuttering for few seconds before the movement is smooth again. This patch resolves this issue, by adding a listener to VM state changes and changing the update interval when the VM state changes to RUNNING. The update_displaychangelistener() function updates the internal timer, and the display is refreshed immediately if the timer is expired. Signed-off-by: Juraj Marcin <jmarcin@redhat.com> Reviewed-by: Marc-André Lureau <marcandre.lureau@redhat.com> Reviewed-by: Peter Xu <peterx@redhat.com> Reviewed-by: Daniel P. Berrangé <berrange@redhat.com> Link: https://lore.kernel.org/r/20250521151616.3951178-1-jmarcin@redhat.com Signed-off-by: Peter Xu <peterx@redhat.com>
2025-06-23tests/qtest: Remove migration-helpers.cFabiano Rosas1-530/+0
Commit 407bc4bf90 ("qapi: Move include/qapi/qmp/ to include/qobject/") brought the migration-helpers.c back by mistake. This file has been replaced with migration/migration-qmp.c and migration/migration-util.c. Fixes: 407bc4bf90 ("qapi: Move include/qapi/qmp/ to include/qobject/") Signed-off-by: Fabiano Rosas <farosas@suse.de> Message-id: 20200310152141.13959-1-peter.maydell@linaro.org Reviewed-by: Markus Armbruster <armbru@redhat.com> Link: https://lore.kernel.org/r/20250523123023.19284-1-farosas@suse.de Signed-off-by: Peter Xu <peterx@redhat.com>
2025-06-23migration/ram: avoid to do log clear in the last roundYanfei Xu1-7/+15
There won't be any ram sync after the stage of save_complete, therefore it's unnecessary to do manually protect for dirty pages being sent. Skip to do this in last round can reduce noticeable downtime. Signed-off-by: Yanfei Xu <yanfei.xu@bytedance.com> Tested-by: Fabiano Rosas <farosas@suse.de> Reviewed-by: Fabiano Rosas <farosas@suse.de> Link: https://lore.kernel.org/r/20250514115827.3216082-1-yanfei.xu@bytedance.com [peterx: add comments] Signed-off-by: Peter Xu <peterx@redhat.com>
2025-06-23linux-user: fix resource leaks in gen-vdsoDaniel P. Berrangé1-11/+16
There are a number of resource leaks in gen-vdso. In theory they are harmless because this is a short lived process, but when building QEMU with --extra-cflags="-fsanitize=address" problems ensure. The gen-vdso program is run as part of the build, and that aborts due to the sanitizer identifying memory leaks, leaving QEMU unbuildable. FAILED: libqemu-x86_64-linux-user.a.p/vdso.c.inc /var/home/berrange/src/virt/qemu/build/linux-user/gen-vdso -o libqemu-x86_64-linux-user.a.p/vdso.c.inc ../linux-user/x86_64/vdso.so ================================================================= ==1696332==ERROR: LeakSanitizer: detected memory leaks Direct leak of 2968 byte(s) in 1 object(s) allocated from: #0 0x56495873f1f3 (/var/home/berrange/src/virt/qemu/build/linux-user/gen-vdso+0xa11f3) (BuildId: b69e241ad44719b6f3934f3c71dfc6727e8bdb12) #1 0x564958780b90 (/var/home/berrange/src/virt/qemu/build/linux-user/gen-vdso+0xe2b90) (BuildId: b69e241ad44719b6f3934f3c71dfc6727e8bdb12) This complaint is about the 'buf' variable, however, the FILE objects are also leaked in some error scenarios, so this fix refactors the cleanup paths to fix all leaks. For completeness it also reports an error if fclose() fails on 'inf'. Signed-off-by: Daniel P. Berrangé <berrange@redhat.com> Tested-by: Arusekk <floss@arusekk.pl> Signed-off-by: Richard Henderson <richard.henderson@linaro.org> Message-ID: <20250513150346.1328217-1-berrange@redhat.com>
2025-06-23linux-user/aarch64: Update hwcap bits from 6.14Richard Henderson1-3/+72
Reviewed-by: Peter Maydell <peter.maydell@linaro.org> Signed-off-by: Richard Henderson <richard.henderson@linaro.org>
2025-06-23tcg: Split out tcg_gen_gvec_dup_imm_varRichard Henderson2-2/+11
Reviewed-by: Peter Maydell <peter.maydell@linaro.org> Signed-off-by: Richard Henderson <richard.henderson@linaro.org>
2025-06-23tcg: Split out tcg_gen_gvec_{add,sub}_varRichard Henderson2-6/+35
Reviewed-by: Peter Maydell <peter.maydell@linaro.org> Signed-off-by: Richard Henderson <richard.henderson@linaro.org>
2025-06-23tcg: Split out tcg_gen_gvec_mov_varRichard Henderson2-6/+19
Reviewed-by: Peter Maydell <peter.maydell@linaro.org> Signed-off-by: Richard Henderson <richard.henderson@linaro.org>
2025-06-23tcg: Split out tcg_gen_gvec_3_varRichard Henderson2-40/+95
Reviewed-by: Peter Maydell <peter.maydell@linaro.org> Signed-off-by: Richard Henderson <richard.henderson@linaro.org>
2025-06-23tcg: Split out tcg_gen_gvec_2_varRichard Henderson2-35/+64
Reviewed-by: Peter Maydell <peter.maydell@linaro.org> Signed-off-by: Richard Henderson <richard.henderson@linaro.org>
2025-06-23tcg: Add base arguments to check_overlap_[234]Richard Henderson1-25/+36
Reviewed-by: Peter Maydell <peter.maydell@linaro.org> Signed-off-by: Richard Henderson <richard.henderson@linaro.org>
2025-06-23tcg: Add dbase argument to expand_clrRichard Henderson1-18/+18
Reviewed-by: Peter Maydell <peter.maydell@linaro.org> Signed-off-by: Richard Henderson <richard.henderson@linaro.org>
2025-06-23tcg: Add dbase argument to do_dupRichard Henderson1-16/+17
Reviewed-by: Peter Maydell <peter.maydell@linaro.org> Signed-off-by: Richard Henderson <richard.henderson@linaro.org>
2025-06-23tcg: Add dbase argument to do_dup_storeRichard Henderson1-8/+8
Reviewed-by: Peter Maydell <peter.maydell@linaro.org> Signed-off-by: Richard Henderson <richard.henderson@linaro.org>
2025-06-20i386/tdx: handle TDG.VP.VMCALL<GetQuote>Isaku Yamahata8-3/+582
Add property "quote-generation-socket" to tdx-guest, which is a property of type SocketAddress to specify Quote Generation Service(QGS). On request of GetQuote, it connects to the QGS socket, read request data from shared guest memory, send the request data to the QGS, and store the response into shared guest memory, at last notify TD guest by interrupt. command line example: qemu-system-x86_64 \ -object '{"qom-type":"tdx-guest","id":"tdx0","quote-generation-socket":{"type":"unix", "path":"/var/run/tdx-qgs/qgs.socket"}}' \ -machine confidential-guest-support=tdx0 Note, above example uses the unix socket. It can be other types, like vsock, which depends on the implementation of QGS. To avoid no response from QGS server, setup a timer for the transaction. If timeout, make it an error and interrupt guest. Define the threshold of time to 30s at present, maybe change to other value if not appropriate. Signed-off-by: Isaku Yamahata <isaku.yamahata@intel.com> Co-developed-by: Chenyi Qiang <chenyi.qiang@intel.com> Signed-off-by: Chenyi Qiang <chenyi.qiang@intel.com> Co-developed-by: Xiaoyao Li <xiaoyao.li@intel.com> Signed-off-by: Xiaoyao Li <xiaoyao.li@intel.com> Tested-by: Xiaoyao Li <xiaoyao.li@intel.com> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2025-06-20i386/tdx: handle TDG.VP.VMCALL<GetTdVmCallInfo>Binbin Wu4-0/+37
Signed-off-by: Binbin Wu <binbin.wu@linux.intel.com> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>