aboutsummaryrefslogtreecommitdiff
path: root/include/sysemu
AgeCommit message (Collapse)AuthorFilesLines
2024-12-20include: Rename sysemu/ -> system/Philippe Mathieu-Daudé60-6113/+0
Headers in include/sysemu/ are not only related to system *emulation*, they are also used by virtualization. Rename as system/ which is clearer. Files renamed manually then mechanical change using sed tool. Signed-off-by: Philippe Mathieu-Daudé <philmd@linaro.org> Reviewed-by: Richard Henderson <richard.henderson@linaro.org> Tested-by: Lei Yang <leiyang@redhat.com> Message-Id: <20241203172445.28576-1-philmd@linaro.org>
2024-11-04Merge tag 'migration-20241030-pull-request' of ↵Peter Maydell1-0/+14
https://gitlab.com/peterx/qemu into staging Migration pull request for softfreeze v2: - Patch "migration: Move cpu-throttle.c from system to migration", fix build on MacOS, and subject spelling NOTE: checkpatch.pl could report a false positive on this branch: WARNING: added, moved or deleted file(s), does MAINTAINERS need updating? #21: {include/sysemu => migration}/cpu-throttle.h | 0 That's covered by "F: migration/" entry. Changelog: - Peter's cleanup patch on migrate_fd_cleanup() - Peter's cleanup patch to introduce thread name macros - Hanna's error path fix for vmstate subsection save()s - Hyman's auto converge enhancement on background dirty sync - Peter's additional tracepoints for save state entries - Thomas's build fix for OpenBSD in dirtyrate.c - Peter's deprecation of query-migrationthreads command - Peter's cleanup/fixes from the "export misc.h" series - Maciej's two small patches from multifd+vfio series # -----BEGIN PGP SIGNATURE----- # # iIgEABYKADAWIQS5GE3CDMRX2s990ak7X8zN86vXBgUCZyTbVRIccGV0ZXJ4QHJl # ZGhhdC5jb20ACgkQO1/MzfOr1wan3wD+L4TVNDc34Hy4mvWu7u1lCOePX0GBdUEc # oEeBGblwbrcBAIR8d+5z9O5YcWH1coozG1aUC4qCtSHHk5TGbJk4/UUD # =XB5Q # -----END PGP SIGNATURE----- # gpg: Signature made Fri 01 Nov 2024 13:44:53 GMT # gpg: using EDDSA key B9184DC20CC457DACF7DD1A93B5FCCCDF3ABD706 # gpg: issuer "peterx@redhat.com" # gpg: Good signature from "Peter Xu <xzpeter@gmail.com>" [marginal] # gpg: aka "Peter Xu <peterx@redhat.com>" [marginal] # gpg: WARNING: This key is not certified with sufficiently trusted signatures! # gpg: It is not certain that the signature belongs to the owner. # Primary key fingerprint: B918 4DC2 0CC4 57DA CF7D D1A9 3B5F CCCD F3AB D706 * tag 'migration-20241030-pull-request' of https://gitlab.com/peterx/qemu: migration/multifd: Zero p->flags before starting filling a packet migration/ram: Add load start trace event migration: Drop migration_is_idle() migration: Drop migration_is_setup_or_active() migration: Unexport ram_mig_init() migration: Unexport dirty_bitmap_mig_init() migration: Take migration object refcount earlier for threads migration: Deprecate query-migrationthreads command migration/dirtyrate: Silence warning about strcpy() on OpenBSD tests/migration: Add case for periodic ramblock dirty sync migration: Support periodic RAMBlock dirty bitmap sync migration: Remove "rs" parameter in migration_bitmap_sync_precopy migration: Move cpu-throttle.c from system to migration migration: Stop CPU throttling conditionally accel/tcg/icount-common: Remove the reference to the unused header file migration: Ensure vmstate_save() sets errp migration: Put thread names together with macros migration: Cleanup migrate_fd_cleanup() on accessing to_dst_file Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
2024-10-31migration: Support periodic RAMBlock dirty bitmap syncHyman Huang1-0/+14
When VM is configured with huge memory, the current throttle logic doesn't look like to scale, because migration_trigger_throttle() is only called for each iteration, so it won't be invoked for a long time if one iteration can take a long time. The periodic dirty sync aims to fix the above issue by synchronizing the ramblock from remote dirty bitmap and, when necessary, triggering the CPU throttle multiple times during a long iteration. This is a trade-off between synchronization overhead and CPU throttle impact. Signed-off-by: Hyman Huang <yong.huang@smartx.com> Reviewed-by: Fabiano Rosas <farosas@suse.de> Link: https://lore.kernel.org/r/f61f1b3653f2acf026901103e1c73d157d38b08f.1729146786.git.yong.huang@smartx.com [peterx: make prev_cnt global, and reset for each migration] Signed-off-by: Peter Xu <peterx@redhat.com>
2024-10-31core/machine: Make create_default_memdev machine a virtual methodDorjoy Chowdhury1-0/+2
This is in preparation for the next commit where the nitro-enclave machine type will need to instead use a memfd backend, for the built-in vhost-user-vsock device to work. Signed-off-by: Dorjoy Chowdhury <dorjoychy111@gmail.com> Reviewed-by: Alexander Graf <graf@amazon.com> Link: https://lore.kernel.org/r/20241008211727.49088-5-dorjoychy111@gmail.com Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2024-10-17KVM: Rename KVMState->nr_slots to nr_slots_maxPeter Xu1-2/+2
This value used to reflect the maximum supported memslots from KVM kernel. Rename it to be clearer. Reviewed-by: David Hildenbrand <david@redhat.com> Signed-off-by: Peter Xu <peterx@redhat.com> Link: https://lore.kernel.org/r/20240917163835.194664-5-peterx@redhat.com Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2024-10-17KVM: Rename KVMMemoryListener.nr_used_slots to nr_slots_usedPeter Xu1-1/+1
This will make all nr_slots counters to be named in the same manner. Reviewed-by: David Hildenbrand <david@redhat.com> Signed-off-by: Peter Xu <peterx@redhat.com> Link: https://lore.kernel.org/r/20240917163835.194664-4-peterx@redhat.com Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2024-10-17KVM: Dynamic sized kvm memslots arrayPeter Xu1-0/+1
Zhiyi reported an infinite loop issue in VFIO use case. The cause of that was a separate discussion, however during that I found a regression of dirty sync slowness when profiling. Each KVMMemoryListerner maintains an array of kvm memslots. Currently it's statically allocated to be the max supported by the kernel. However after Linux commit 4fc096a99e ("KVM: Raise the maximum number of user memslots"), the max supported memslots reported now grows to some number large enough so that it may not be wise to always statically allocate with the max reported. What's worse, QEMU kvm code still walks all the allocated memslots entries to do any form of lookups. It can drastically slow down all memslot operations because each of such loop can run over 32K times on the new kernels. Fix this issue by making the memslots to be allocated dynamically. Here the initial size was set to 16 because it should cover the basic VM usages, so that the hope is the majority VM use case may not even need to grow at all (e.g. if one starts a VM with ./qemu-system-x86_64 by default it'll consume 9 memslots), however not too large to waste memory. There can also be even better way to address this, but so far this is the simplest and should be already better even than before we grow the max supported memslots. For example, in the case of above issue when VFIO was attached on a 32GB system, there are only ~10 memslots used. So it could be good enough as of now. In the above VFIO context, measurement shows that the precopy dirty sync shrinked from ~86ms to ~3ms after this patch applied. It should also apply to any KVM enabled VM even without VFIO. NOTE: we don't have a FIXES tag for this patch because there's no real commit that regressed this in QEMU. Such behavior existed for a long time, but only start to be a problem when the kernel reports very large nr_slots_max value. However that's pretty common now (the kernel change was merged in 2021) so we attached cc:stable because we'll want this change to be backported to stable branches. Cc: qemu-stable <qemu-stable@nongnu.org> Reported-by: Zhiyi Guo <zhguo@redhat.com> Tested-by: Zhiyi Guo <zhguo@redhat.com> Signed-off-by: Peter Xu <peterx@redhat.com> Acked-by: David Hildenbrand <david@redhat.com> Reviewed-by: Fabiano Rosas <farosas@suse.de> Link: https://lore.kernel.org/r/20240917163835.194664-2-peterx@redhat.com Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2024-10-15dma: Fix function names in documentationAkihiko Odaki1-6/+5
Ensure the function names match. Signed-off-by: Akihiko Odaki <akihiko.odaki@daynix.com> Message-id: 20241012-dma-v2-1-6afddf5f3c8d@daynix.com Reviewed-by: Peter Maydell <peter.maydell@linaro.org> Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
2024-10-15vl.c: Remove pxa2xx-specific -portrait and -rotate optionsPeter Maydell1-1/+0
The ``-portrait`` and ``-rotate`` options were documented as only working with the PXA LCD device, and all the machine types using that display device were removed in 9.2. These options were intended to simulate a mobile device being rotated by the user, and had three effects: * the display output was rotated by 90, 180 or 270 degrees (implemented in the PXA display device models) * the mouse/trackpad input was rotated the opposite way (implemented in generic code) * the machine model would signal to the guest about its orientation (implemented by e.g. the spitz machine model) Of these three things, the input-rotation was coded without being restricted to boards which supported the full set of device-rotation handling, so in theory the options were usable on other machine models with odd effects (rotating input but not display output). But this was never intended or documented behaviour, so we can reasonably drop these command line arguments without a formal deprecate-and-drop cycle for them. Remove the options, and their implementation and documentation. Describe the removal in removed-features.rst. Signed-off-by: Peter Maydell <peter.maydell@linaro.org> Reviewed-by: Richard Henderson <richard.henderson@linaro.org> Reviewed-by: Philippe Mathieu-Daudé <philmd@linaro.org> Message-id: 20241003140010.1653808-7-peter.maydell@linaro.org
2024-10-04Merge tag 'for-upstream' of https://gitlab.com/bonzini/qemu into stagingPeter Maydell1-2/+2
* pc: Add a description for the i8042 property * kvm: support for nested FRED * tests/unit: fix warning when compiling test-nested-aio-poll with LTO * kvm: refactoring of VM creation * target/i386: expose IBPB-BRTYPE and SBPB CPUID bits to the guest * hw/char: clean up serial * remove virtfs-proxy-helper * target/i386/kvm: Report which action failed in kvm_arch_put/get_registers * qom: improvements to object_resolve_path*() # -----BEGIN PGP SIGNATURE----- # # iQFIBAABCAAyFiEE8TM4V0tmI4mGbHaCv/vSX3jHroMFAmb++MsUHHBib256aW5p # QHJlZGhhdC5jb20ACgkQv/vSX3jHroPVnwf/cdvfxvDm22tEdlh8vHlV17HtVdcC # Hw334M/3PDvbTmGzPBg26lzo4nFS6SLrZ8ETCeqvuJrtKzqVk9bI8ssZW5KA4ijM # nkxguRPHO8E6U33ZSucc+Hn56+bAx4I2X80dLKXJ87OsbMffIeJ6aHGSEI1+fKVh # pK7q53+Y3lQWuRBGhDIyKNuzqU4g+irpQwXOhux63bV3ADadmsqzExP6Gmtl8OKM # DylPu1oK7EPZumlSiJa7Gy1xBqL4Rc4wGPNYx2RVRjp+i7W2/Y1uehm3wSBw+SXC # a6b7SvLoYfWYS14/qCF4cBL3sJH/0f/4g8ZAhDDxi2i5kBr0/5oioDyE/A== # =/zo4 # -----END PGP SIGNATURE----- # gpg: Signature made Thu 03 Oct 2024 21:04:27 BST # gpg: using RSA key F13338574B662389866C7682BFFBD25F78C7AE83 # gpg: issuer "pbonzini@redhat.com" # gpg: Good signature from "Paolo Bonzini <bonzini@gnu.org>" [full] # gpg: aka "Paolo Bonzini <pbonzini@redhat.com>" [full] # Primary key fingerprint: 46F5 9FBD 57D6 12E7 BFD4 E2F7 7E15 100C CD36 69B1 # Subkey fingerprint: F133 3857 4B66 2389 866C 7682 BFFB D25F 78C7 AE83 * tag 'for-upstream' of https://gitlab.com/bonzini/qemu: (23 commits) qom: update object_resolve_path*() documentation qom: set *ambiguous on all paths qom: rename object_resolve_path_type() "ambiguousp" target/i386/kvm: Report which action failed in kvm_arch_put/get_registers kvm: Allow kvm_arch_get/put_registers to accept Error** accel/kvm: refactor dirty ring setup minikconf: print error entirely on stderr 9p: remove 'proxy' filesystem backend driver hw/char: Extract serial-mm hw/char/serial.h: Extract serial-isa.h hw: Remove unused inclusion of hw/char/serial.h target/i386: Expose IBPB-BRTYPE and SBPB CPUID bits to the guest kvm: refactor core virtual machine creation into its own function kvm/i386: replace identity_base variable with a constant kvm/i386: refactor kvm_arch_init and split it into smaller functions kvm: replace fprintf with error_report()/printf() in kvm_init() kvm/i386: fix return values of is_host_cpu_intel() kvm/i386: make kvm_filter_msr() and related definitions private to kvm module hw/i386/pc: Add a description for the i8042 property tests/unit: remove block layer code from test-nested-aio-poll ... Signed-off-by: Peter Maydell <peter.maydell@linaro.org> # Conflicts: # hw/arm/Kconfig # hw/arm/pxa2xx.c
2024-10-03kvm: Allow kvm_arch_get/put_registers to accept Error**Julia Suvorova1-2/+2
This is necessary to provide discernible error messages to the caller. Signed-off-by: Julia Suvorova <jusual@redhat.com> Reviewed-by: Peter Xu <peterx@redhat.com> Link: https://lore.kernel.org/r/20240927104743.218468-2-jusual@redhat.com Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2024-10-03block-backend: Remove deadcodeDr. David Alan Gilbert1-8/+0
blk_by_public last use was removed in 2017 by c61791fc23 ("block: add aio_context field in ThrottleGroupMember") blk_activate last use was removed earlier this year by eef0bae3a7 ("migration: Remove block migration") blk_add_insert_bs_notifier, blk_op_block_all, blk_op_unblock_all last uses were removed in 2016 by ef8875b549 ("virtio-scsi: Remove op blocker for dataplane") blk_iostatus_disable last use was removed in 2016 by 66a0fae438 ("blockjob: Don't touch BDS iostatus") Remove them. Signed-off-by: Dr. David Alan Gilbert <dave@treblig.org> Reviewed-by: Thomas Huth <thuth@redhat.com> Reviewed-by: Michael Tokarev <mjt@tls.msk.ru> Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>
2024-10-03replay: Remove unused replay_disable_eventsDr. David Alan Gilbert1-2/+0
replay_disable_events has been unused since 2019's c8aa7895eb ("replay: don't drain/flush bdrv queue while RR is working") Remove it. Signed-off-by: Dr. David Alan Gilbert <dave@treblig.org> Reviewed-by: Pavel Dovgalyuk <pavel.dovgalyuk@ispras.ru> Reviewed-by: Thomas Huth <thuth@redhat.com> Reviewed-by: Michael Tokarev <mjt@tls.msk.ru> Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>
2024-09-24reset: Use ResetType for qemu_devices_reset() and MachineClass::reset()Juraj Marcin1-2/+3
Currently, both qemu_devices_reset() and MachineClass::reset() use ShutdownCause for the reason of the reset. However, the Resettable interface uses ResetState, so ShutdownCause needs to be translated to ResetType somewhere. Translating it qemu_devices_reset() makes adding new reset types harder, as they cannot always be matched to a single ShutdownCause here, and devices may need to check the ResetType to determine what to reset and if to reset at all. This patch moves this translation up in the call stack to qemu_system_reset() and updates all MachineClass children to use the ResetType instead. Message-ID: <20240904103722.946194-2-jmarcin@redhat.com> Reviewed-by: David Hildenbrand <david@redhat.com> Reviewed-by: Peter Maydell <peter.maydell@linaro.org> Signed-off-by: Juraj Marcin <jmarcin@redhat.com> Signed-off-by: David Hildenbrand <david@redhat.com>
2024-09-13system: Remove support for CRIS targetPhilippe Mathieu-Daudé1-1/+0
We are about to remove the CRIS target, so remove the sysemu part. This remove the CRIS 'none' machine. Signed-off-by: Philippe Mathieu-Daudé <philmd@linaro.org> Reviewed-by: Thomas Huth <thuth@redhat.com> Reviewed-by: Richard Henderson <richard.henderson@linaro.org> Acked-by: Edgar E. Iglesias <edgar.iglesias@amd.com> Message-ID: <20240904143603.52934-13-philmd@linaro.org>
2024-09-13hvf: Split up hv_vm_create logic per archDanny Canter1-0/+1
This is preliminary work to split up hv_vm_create logic per platform so we can support creating VMs with > 64GB of RAM on Apple Silicon machines. This is done via ARM HVF's hv_vm_config_create() (and other APIs that modify this config that will be coming in future patches). This should have no behavioral difference at all as hv_vm_config_create() just assigns the same default values as if you just passed NULL to the function. Signed-off-by: Danny Canter <danny_canter@apple.com> Message-id: 20240828111552.93482-3-danny_canter@apple.com Reviewed-by: Peter Maydell <peter.maydell@linaro.org> Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
2024-09-13kvm: Use 'unsigned long' for request argument in functions wrapping ioctl()Johannes Stoelp2-8/+17
Change the data type of the ioctl _request_ argument from 'int' to 'unsigned long' for the various accel/kvm functions which are essentially wrappers around the ioctl() syscall. The correct type for ioctl()'s 'request' argument is confused: * POSIX defines the request argument as 'int' * glibc uses 'unsigned long' in the prototype in sys/ioctl.h * the glibc info documentation uses 'int' * the Linux manpage uses 'unsigned long' * the Linux implementation of the syscall uses 'unsigned int' If we wrap ioctl() with another function which uses 'int' as the type for the request argument, then requests with the 0x8000_0000 bit set will be sign-extended when the 'int' is cast to 'unsigned long' for the call to ioctl(). On x86_64 one such example is the KVM_IRQ_LINE_STATUS request. Bit requests with the _IOC_READ direction bit set, will have the high bit set. Fortunately the Linux Kernel truncates the upper 32bit of the request on 64bit machines (because it uses 'unsigned int', and see also Linus Torvalds' comments in https://sourceware.org/bugzilla/show_bug.cgi?id=14362 ) so this doesn't cause active problems for us. However it is more consistent to follow the glibc ioctl() prototype when we define functions that are essentially wrappers around ioctl(). This resolves a Coverity issue where it points out that in kvm_get_xsave() we assign a value (KVM_GET_XSAVE or KVM_GET_XSAVE2) to an 'int' variable which can't hold it without overflow. Resolves: Coverity CID 1547759 Signed-off-by: Johannes Stoelp <johannes.stoelp@gmail.com> Signed-off-by: Peter Maydell <peter.maydell@linaro.org> Reviewed-by: Eric Blake <eblake@redhat.com> Message-id: 20240815122747.3053871-1-peter.maydell@linaro.org [PMM: Rebased patch, adjusted commit message, included note about Coverity fix, updated the type of the local var in kvm_get_xsave, updated the comment in the KVMState struct definition] Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
2024-09-10qapi/cryptodev: Rename QCryptodevBackendAlgType to *Algo, and drop prefixMarkus Armbruster1-1/+1
QAPI's 'prefix' feature can make the connection between enumeration type and its constants less than obvious. It's best used with restraint. QCryptodevBackendAlgType has a 'prefix' that overrides the generated enumeration constants' prefix to QCRYPTODEV_BACKEND_ALG. We could simply drop 'prefix', but I think the abbreviation "alg" is less than clear. Additionally rename the type to QCryptodevBackendAlgoType. The prefix becomes QCRYPTODEV_BACKEND_ALGO_TYPE. Signed-off-by: Markus Armbruster <armbru@redhat.com> Reviewed-by: Daniel P. Berrangé <berrange@redhat.com> Message-ID: <20240904111836.3273842-19-armbru@redhat.com>
2024-08-16Revert "replay: stop us hanging in rr_wait_io_event"Nicholas Piggin1-5/+0
This reverts commit 1f881ea4a444ef36a8b6907b0b82be4b3af253a2. That commit causes reverse_debugging.py test failures, and does not seem to solve the root cause of the problem x86-64 still hangs in record/replay tests. The problem with short-cutting the iowait that was taken during record phase is that related events will not get consumed at the same points (e.g., reading the clock). A hang with zero icount always seems to be a symptom of an earlier problem that has caused the recording to become out of synch with the execution and consumption of events by replay. Acked-by: Alex Bennée <alex.bennee@linaro.org> Signed-off-by: Nicholas Piggin <npiggin@gmail.com> Message-Id: <20240813050638.446172-6-npiggin@gmail.com> Signed-off-by: Alex Bennée <alex.bennee@linaro.org> Message-Id: <20240813202329.1237572-14-alex.bennee@linaro.org>
2024-08-16replay: allow runstate shutdown->running when replaying traceNicholas Piggin1-0/+1
When replaying a trace, it is possible to go from shutdown to running with a reverse-debugging step. This can be useful if the problem being debugged triggers a reset or shutdown. This can be tested by making a recording of a machine that shuts down, then using -action shutdown=pause when replaying it. Continuing to the end of the trace then reverse-stepping in gdb crashes due to invalid runstate transition. Just permitting the transition seems to be all that's necessary for reverse-debugging to work well in such a state. Reviewed-by: Alex Bennée <alex.bennee@linaro.org> Reviewed-by: Pavel Dovgalyuk <Pavel.Dovgalyuk@ispras.ru> Signed-off-by: Nicholas Piggin <npiggin@gmail.com> Message-Id: <20240813050638.446172-5-npiggin@gmail.com> Signed-off-by: Alex Bennée <alex.bennee@linaro.org> Message-Id: <20240813202329.1237572-13-alex.bennee@linaro.org>
2024-07-26accel/kvm: Introduce kvm_create_and_park_vcpu() helperHarsh Prateek Bora1-0/+8
There are distinct helpers for creating and parking a KVM vCPU. However, there can be cases where a platform needs to create and immediately park the vCPU during early stages of vcpu init which can later be reused when vcpu thread gets initialized. This would help detect failures with kvm_create_vcpu at an early stage. Suggested-by: Nicholas Piggin <npiggin@gmail.com> Reviewed-by: Nicholas Piggin <npiggin@gmail.com> Signed-off-by: Harsh Prateek Bora <harshpb@linux.ibm.com> Signed-off-by: Nicholas Piggin <npiggin@gmail.com>
2024-07-24Merge tag 'pull-vfio-20240723-1' of https://github.com/legoater/qemu into ↵Richard Henderson2-3/+15
staging vfio queue: * IOMMUFD Dirty Tracking support * Fix for a possible SEGV in IOMMU type1 container * Dropped initialization of host IOMMU device with mdev devices # -----BEGIN PGP SIGNATURE----- # # iQIzBAABCAAdFiEEoPZlSPBIlev+awtgUaNDx8/77KEFAmafyVUACgkQUaNDx8/7 # 7KGebRAAzEYxvstDxSPNF+1xx937TKbRpiKYtspTfEgu4Ht50MwO2ZqnVWzTBSwa # qcjhDf2avMBpBvkp4O9fR7nXR0HRN2KvYrBSThZ3Qpqu4KjxCAGcHI5uYmgfizYh # BBLrw3eWME5Ry220TinQF5KFl50vGq7Z/mku5N5Tgj2qfTfCXYK1Kc19SyAga49n # LSokTIjZAGJa4vxrE7THawaEUjFRjfCJey64JUs/TPJaGr4R1snJcWgETww6juUE # 9OSw/xl0AoQhaN/ZTRC1qCsBLUI2MVPsC+x+vqVK62HlTjCx+uDRVQ8KzfDzjCeH # gaLkMjxJSuJZMpm4UU7DBzDGEGcEBCGeNyFt37BSqqPPpX55CcFhj++d8vqTiwpF # YzmTNd/znxcZTw6OJN9sQZohh+NeS86CVZ3x31HD3dXifhRf17jbh7NoIyi+0ZCb # N+mytOH5BXsD+ddwbk+yMaxXV43Fgz7ThG5tB1tjhhNtLZHDA5ezFvGZ5F/FJrqE # xAbjOhz5MC+RcOVNSzQJCULNqFpfE6Gqeys6btEDm/ltf4LpAe6W1HYuv8BJc19T # UsqGK2yKAuQX8GErYxJ1zqZCttVrgpsmXFYTC5iGbxC84mvsF0Iti96IdXz9gfzN # Vlb2OxoefcOwVqIhbkvTZW0ZwYGGDDPAYhLMfr5lSuRqj123OOo= # =cViP # -----END PGP SIGNATURE----- # gpg: Signature made Wed 24 Jul 2024 01:16:37 AM AEST # gpg: using RSA key A0F66548F04895EBFE6B0B6051A343C7CFFBECA1 # gpg: Good signature from "Cédric Le Goater <clg@kaod.org>" [undefined] # gpg: WARNING: This key is not certified with a trusted signature! # gpg: There is no indication that the signature belongs to the owner. # Primary key fingerprint: A0F6 6548 F048 95EB FE6B 0B60 51A3 43C7 CFFB ECA1 * tag 'pull-vfio-20240723-1' of https://github.com/legoater/qemu: vfio/common: Allow disabling device dirty page tracking vfio/migration: Don't block migration device dirty tracking is unsupported vfio/iommufd: Implement VFIOIOMMUClass::query_dirty_bitmap support vfio/iommufd: Implement VFIOIOMMUClass::set_dirty_tracking support vfio/iommufd: Probe and request hwpt dirty tracking capability vfio/{iommufd, container}: Invoke HostIOMMUDevice::realize() during attach_device() vfio/iommufd: Add hw_caps field to HostIOMMUDeviceCaps vfio/{iommufd,container}: Remove caps::aw_bits vfio/iommufd: Introduce auto domain creation vfio/ccw: Don't initialize HOST_IOMMU_DEVICE with mdev vfio/ap: Don't initialize HOST_IOMMU_DEVICE with mdev vfio/iommufd: Return errno in iommufd_cdev_attach_ioas_hwpt() backends/iommufd: Extend iommufd_backend_get_device_info() to fetch HW capabilities vfio/iommufd: Don't initialize nor set a HOST_IOMMU_DEVICE with mdev vfio/pci: Extract mdev check into an helper hw/vfio/container: Fix SIGSEV on vfio_container_instance_finalize() Signed-off-by: Richard Henderson <richard.henderson@linaro.org>
2024-07-24Merge tag 'for-upstream' of https://gitlab.com/bonzini/qemu into stagingRichard Henderson1-0/+32
* target/i386/kvm: support for reading RAPL MSRs using a helper program * hpet: emulation improvements # -----BEGIN PGP SIGNATURE----- # # iQFIBAABCAAyFiEE8TM4V0tmI4mGbHaCv/vSX3jHroMFAmaelL4UHHBib256aW5p # QHJlZGhhdC5jb20ACgkQv/vSX3jHroMXoQf+K77lNlHLETSgeeP3dr7yZPOmXjjN # qFY/18jiyLw7MK1rZC09fF+n9SoaTH8JDKupt0z9M1R10HKHLIO04f8zDE+dOxaE # Rou3yKnlTgFPGSoPPFr1n1JJfxtYlLZRoUzaAcHUaa4W7JR/OHJX90n1Rb9MXeDk # jV6P0v1FWtIDdM6ERm9qBGoQdYhj6Ra2T4/NZKJFXwIhKEkxgu4yO7WXv8l0dxQz # jE4fKotqAvrkYW1EsiVZm30lw/19duhvGiYeQXoYhk8KKXXjAbJMblLITSNWsCio # 3l6Uud/lOxekkJDAq5nH3H9hCBm0WwvwL+0vRf3Mkr+/xRGvrhtmUdp8NQ== # =00mB # -----END PGP SIGNATURE----- # gpg: Signature made Tue 23 Jul 2024 03:19:58 AM AEST # gpg: using RSA key F13338574B662389866C7682BFFBD25F78C7AE83 # gpg: issuer "pbonzini@redhat.com" # gpg: Good signature from "Paolo Bonzini <bonzini@gnu.org>" [full] # gpg: aka "Paolo Bonzini <pbonzini@redhat.com>" [full] * tag 'for-upstream' of https://gitlab.com/bonzini/qemu: hpet: avoid timer storms on periodic timers hpet: store full 64-bit target value of the counter hpet: accept 64-bit reads and writes hpet: place read-only bits directly in "new_val" hpet: remove unnecessary variable "index" hpet: ignore high bits of comparator in 32-bit mode hpet: fix and cleanup persistence of interrupt status Add support for RAPL MSRs in KVM/Qemu tools: build qemu-vmsr-helper qio: add support for SO_PEERCRED for socket channel target/i386: do not crash if microvm guest uses SGX CPUID leaves Signed-off-by: Richard Henderson <richard.henderson@linaro.org>
2024-07-23vfio/iommufd: Implement VFIOIOMMUClass::query_dirty_bitmap supportJoao Martins1-0/+4
ioctl(iommufd, IOMMU_HWPT_GET_DIRTY_BITMAP, arg) is the UAPI that fetches the bitmap that tells what was dirty in an IOVA range. A single bitmap is allocated and used across all the hwpts sharing an IOAS which is then used in log_sync() to set Qemu global bitmaps. Signed-off-by: Joao Martins <joao.m.martins@oracle.com> Reviewed-by: Cédric Le Goater <clg@redhat.com> Reviewed-by: Eric Auger <eric.auger@redhat.com> Reviewed-by: Zhenzhong Duan <zhenzhong.duan@intel.com>
2024-07-23vfio/iommufd: Implement VFIOIOMMUClass::set_dirty_tracking supportJoao Martins1-0/+2
ioctl(iommufd, IOMMU_HWPT_SET_DIRTY_TRACKING, arg) is the UAPI that enables or disables dirty page tracking. The ioctl is used if the hwpt has been created with dirty tracking supported domain (stored in hwpt::flags) and it is called on the whole list of iommu domains. Signed-off-by: Joao Martins <joao.m.martins@oracle.com> Reviewed-by: Zhenzhong Duan <zhenzhong.duan@intel.com> Reviewed-by: Eric Auger <eric.auger@redhat.com>
2024-07-23vfio/iommufd: Add hw_caps field to HostIOMMUDeviceCapsJoao Martins1-0/+4
Store the value of @caps returned by iommufd_backend_get_device_info() in a new field HostIOMMUDeviceCaps::hw_caps. Right now the only value is whether device IOMMU supports dirty tracking (IOMMU_HW_CAP_DIRTY_TRACKING). This is in preparation for HostIOMMUDevice::realize() being called early during attach_device(). Signed-off-by: Joao Martins <joao.m.martins@oracle.com> Reviewed-by: Cédric Le Goater <clg@redhat.com> Reviewed-by: Zhenzhong Duan <zhenzhong.duan@intel.com> Reviewed-by: Eric Auger <eric.auger@redhat.com>
2024-07-23vfio/{iommufd,container}: Remove caps::aw_bitsJoao Martins1-3/+0
Remove caps::aw_bits which requires the bcontainer::iova_ranges being initialized after device is actually attached. Instead defer that to .get_cap() and call vfio_device_get_aw_bits() directly. This is in preparation for HostIOMMUDevice::realize() being called early during attach_device(). Suggested-by: Zhenzhong Duan <zhenzhong.duan@intel.com> Signed-off-by: Joao Martins <joao.m.martins@oracle.com> Reviewed-by: Cédric Le Goater <clg@redhat.com> Reviewed-by: Eric Auger <eric.auger@redhat.com>
2024-07-23vfio/iommufd: Introduce auto domain creationJoao Martins1-0/+5
There's generally two modes of operation for IOMMUFD: 1) The simple user API which intends to perform relatively simple things with IOMMUs e.g. DPDK. The process generally creates an IOAS and attaches to VFIO and mainly performs IOAS_MAP and UNMAP. 2) The native IOMMUFD API where you have fine grained control of the IOMMU domain and model it accordingly. This is where most new feature are being steered to. For dirty tracking 2) is required, as it needs to ensure that the stage-2/parent IOMMU domain will only attach devices that support dirty tracking (so far it is all homogeneous in x86, likely not the case for smmuv3). Such invariant on dirty tracking provides a useful guarantee to VMMs that will refuse incompatible device attachments for IOMMU domains. Dirty tracking insurance is enforced via HWPT_ALLOC, which is responsible for creating an IOMMU domain. This is contrast to the 'simple API' where the IOMMU domain is created by IOMMUFD automatically when it attaches to VFIO (usually referred as autodomains) but it has the needed handling for mdevs. To support dirty tracking with the advanced IOMMUFD API, it needs similar logic, where IOMMU domains are created and devices attached to compatible domains. Essentially mimicking kernel iommufd_device_auto_get_domain(). With mdevs given there's no IOMMU domain it falls back to IOAS attach. The auto domain logic allows different IOMMU domains to be created when DMA dirty tracking is not desired (and VF can provide it), and others where it is. Here it is not used in this way given how VFIODevice migration state is initialized after the device attachment. But such mixed mode of IOMMU dirty tracking + device dirty tracking is an improvement that can be added on. Keep the 'all of nothing' of type1 approach that we have been using so far between container vs device dirty tracking. Signed-off-by: Joao Martins <joao.m.martins@oracle.com> Reviewed-by: Zhenzhong Duan <zhenzhong.duan@intel.com> [ clg: Added ERRP_GUARD() in iommufd_cdev_autodomains_get() ] Signed-off-by: Cédric Le Goater <clg@redhat.com> Reviewed-by: Eric Auger <eric.auger@redhat.com>
2024-07-23backends/iommufd: Extend iommufd_backend_get_device_info() to fetch HW ↵Joao Martins1-1/+1
capabilities The helper will be able to fetch vendor agnostic IOMMU capabilities supported both by hardware and software. Right now it is only iommu dirty tracking. Signed-off-by: Joao Martins <joao.m.martins@oracle.com> Reviewed-by: Zhenzhong Duan <zhenzhong.duan@intel.com> Reviewed-by: Cédric Le Goater <clg@redhat.com> Reviewed-by: Eric Auger <eric.auger@redhat.com>
2024-07-22backends: Initial support for SPDM socket supportHuai-Cheng Kuo1-0/+74
SPDM enables authentication, attestation and key exchange to assist in providing infrastructure security enablement. It's a standard published by the DMTF [1]. SPDM supports multiple transports, including PCIe DOE and MCTP. This patch adds support to QEMU to connect to an external SPDM instance. SPDM support can be added to any QEMU device by exposing a TCP socket to a SPDM server. The server can then implement the SPDM decoding/encoding support, generally using libspdm [2]. This is similar to how the current TPM implementation works and means that the heavy lifting of setting up certificate chains, capabilities, measurements and complex crypto can be done outside QEMU by a well supported and tested library. 1: https://www.dmtf.org/standards/SPDM 2: https://github.com/DMTF/libspdm Signed-off-by: Huai-Cheng Kuo <hchkuo@avery-design.com.tw> Signed-off-by: Chris Browy <cbrowy@avery-design.com> Co-developed-by: Jonathan Cameron <Jonathan.cameron@huawei.com> Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com> [ Changes by WM - Bug fixes from testing ] Signed-off-by: Wilfred Mallawa <wilfred.mallawa@wdc.com> [ Changes by AF: - Convert to be more QEMU-ified - Move to backends as it isn't PCIe specific ] Signed-off-by: Alistair Francis <alistair.francis@wdc.com> Message-Id: <20240703092027.644758-3-alistair.francis@wdc.com> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
2024-07-22accel/kvm: Extract common KVM vCPU {creation,parking} codeSalil Mehta1-0/+25
KVM vCPU creation is done once during the vCPU realization when Qemu vCPU thread is spawned. This is common to all the architectures as of now. Hot-unplug of vCPU results in destruction of the vCPU object in QOM but the corresponding KVM vCPU object in the Host KVM is not destroyed as KVM doesn't support vCPU removal. Therefore, its representative KVM vCPU object/context in Qemu is parked. Refactor architecture common logic so that some APIs could be reused by vCPU Hotplug code of some architectures likes ARM, Loongson etc. Update new/old APIs with trace events. New APIs qemu_{create,park,unpark}_vcpu() can be externally called. No functional change is intended here. Signed-off-by: Salil Mehta <salil.mehta@huawei.com> Reviewed-by: Gavin Shan <gshan@redhat.com> Tested-by: Vishnu Pajjuri <vishnu@os.amperecomputing.com> Reviewed-by: Jonathan Cameron <Jonathan.Cameron@huawei.com> Tested-by: Xianglai Li <lixianglai@loongson.cn> Tested-by: Miguel Luis <miguel.luis@oracle.com> Reviewed-by: Shaoqin Huang <shahuang@redhat.com> Reviewed-by: Vishnu Pajjuri <vishnu@os.amperecomputing.com> Reviewed-by: Nicholas Piggin <npiggin@gmail.com> Tested-by: Zhao Liu <zhao1.liu@intel.com> Reviewed-by: Zhao Liu <zhao1.liu@intel.com> Reviewed-by: Harsh Prateek Bora <harshpb@linux.ibm.com> Reviewed-by: Igor Mammedov <imammedo@redhat.com> Message-Id: <20240716111502.202344-2-salil.mehta@huawei.com> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
2024-07-22Add support for RAPL MSRs in KVM/QemuAnthony Harivel1-0/+32
Starting with the "Sandy Bridge" generation, Intel CPUs provide a RAPL interface (Running Average Power Limit) for advertising the accumulated energy consumption of various power domains (e.g. CPU packages, DRAM, etc.). The consumption is reported via MSRs (model specific registers) like MSR_PKG_ENERGY_STATUS for the CPU package power domain. These MSRs are 64 bits registers that represent the accumulated energy consumption in micro Joules. They are updated by microcode every ~1ms. For now, KVM always returns 0 when the guest requests the value of these MSRs. Use the KVM MSR filtering mechanism to allow QEMU handle these MSRs dynamically in userspace. To limit the amount of system calls for every MSR call, create a new thread in QEMU that updates the "virtual" MSR values asynchronously. Each vCPU has its own vMSR to reflect the independence of vCPUs. The thread updates the vMSR values with the ratio of energy consumed of the whole physical CPU package the vCPU thread runs on and the thread's utime and stime values. All other non-vCPU threads are also taken into account. Their energy consumption is evenly distributed among all vCPUs threads running on the same physical CPU package. To overcome the problem that reading the RAPL MSR requires priviliged access, a socket communication between QEMU and the qemu-vmsr-helper is mandatory. You can specified the socket path in the parameter. This feature is activated with -accel kvm,rapl=true,path=/path/sock.sock Actual limitation: - Works only on Intel host CPU because AMD CPUs are using different MSR adresses. - Only the Package Power-Plane (MSR_PKG_ENERGY_STATUS) is reported at the moment. Signed-off-by: Anthony Harivel <aharivel@redhat.com> Link: https://lore.kernel.org/r/20240522153453.1230389-4-aharivel@redhat.com Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2024-07-09HostIOMMUDevice: Introduce get_page_size_mask() callbackEric Auger1-0/+8
This callback will be used to retrieve the page size mask supported along a given Host IOMMU device. Signed-off-by: Eric Auger <eric.auger@redhat.com> Reviewed-by: Zhenzhong Duan <zhenzhong.duan@intel.com> Reviewed-by: Cédric Le Goater <clg@redhat.com> Reviewed-by: Michael S. Tsirkin <mst@redhat.com>
2024-07-09HostIOMMUDevice : remove Error handle from get_iova_ranges callbackEric Auger1-2/+1
The error handle argument is not used anywhere. let's remove it. Signed-off-by: Eric Auger <eric.auger@redhat.com> Reviewed-by: Cédric Le Goater <clg@redhat.com> Reviewed-by: Zhenzhong Duan <zhenzhong.duan@intel.com> Reviewed-by: Michael S. Tsirkin <mst@redhat.com>
2024-07-01hw/misc/pvpanic: add support for normal shutdownsThomas Weißschuh1-0/+1
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. Acked-by: Cornelia Huck <cohuck@redhat.com> Signed-off-by: Thomas Weißschuh <thomas@t-8ch.de> Message-Id: <20240527-pvpanic-shutdown-v8-5-5a28ec02558b@t-8ch.de> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
2024-06-24Merge tag 'pull-vfio-20240624' of https://github.com/legoater/qemu into stagingRichard Henderson2-0/+121
vfio queue: * Add a host IOMMU device abstraction * VIRTIO-IOMMU/VFIO: Fix host iommu geometry handling * QOMify VFIOContainer # -----BEGIN PGP SIGNATURE----- # # iQIzBAABCAAdFiEEoPZlSPBIlev+awtgUaNDx8/77KEFAmZ541QACgkQUaNDx8/7 # 7KFdnQ/8Dih3HI2qtY93bTxg0lmJ+ZMibojTkEkTu3kSvwoI12wkiSMFKzzTWpZE # UtGyIqQQij8IfQtIz87uQskv7oFiZKG6JWMTAX4uJ8ZIgZiih29/e/38VGEbogBh # yO+1Pqr3ETlyLnQcu9ruBTJ293LXovmD4d9feoaVdURBNZ1EqIh7sv/y7YdUsR+i # tXa6kW1ZIlKBI54o/uuODHWQYyOHs39VtZ6JZvgxVVEQsNikcJsosK9ts9A1EByi # 0roQVXm2QAK/nPXlmMGLvJWzQcdeXQ6W6hzYkO2HqGnCLURnpW+y/ZVbNcxGOOiU # 2G6L0TASlqA3yqCJeLuZZqjM6S2VbnvrA8omyg4QnygIHppYjp2CdcCmUpg6wfze # rkgbVLNasX+le4ss2emuHPh55dLDP20yW83DeGeqSgE//foaJWhtOK/cnvs04zV2 # D6oSAVsOsZ6ozYlQckYnaxIBANDKLRnzCXVZLUCmHxCUhxHuiNJUsHfZYIv/Zxen # C5ZjD/JPgx3onkoKbNfTRTgwOCdXhVPjWnnp7Su49jymsekqdk1ntln4ixDT3Vol # ghQPQLjICBc8qXiOJAcFDwqLf/telPlzUUzvlDeC4BYMnpBAP6rQ3JJ8i0vCCiWv # zKCtmbcDqDRMDpWyJWM3XA/kVKP9i2tNa1R/ej2SleCFLgRapBw= # =3koe # -----END PGP SIGNATURE----- # gpg: Signature made Mon 24 Jun 2024 02:21:24 PM PDT # gpg: using RSA key A0F66548F04895EBFE6B0B6051A343C7CFFBECA1 # gpg: Good signature from "Cédric Le Goater <clg@kaod.org>" [undefined] # gpg: WARNING: This key is not certified with a trusted signature! # gpg: There is no indication that the signature belongs to the owner. # Primary key fingerprint: A0F6 6548 F048 95EB FE6B 0B60 51A3 43C7 CFFB ECA1 * tag 'pull-vfio-20240624' of https://github.com/legoater/qemu: (42 commits) vfio/container: Move vfio_container_destroy() to an instance_finalize() handler vfio/container: Introduce vfio_iommu_legacy_instance_init() vfio/container: Remove vfio_container_init() vfio/container: Remove VFIOContainerBase::ops vfio/container: Introduce an instance_init() handler vfio/container: Switch to QOM vfio/container: Change VFIOContainerBase to use QOM vfio/container: Discover IOMMU type before creating the container vfio/container: Introduce vfio_create_container() vfio/container: Introduce vfio_get_iommu_class_name() vfio/container: Modify vfio_get_iommu_type() to use a container fd vfio/container: Simplify vfio_container_init() vfio/container: Introduce vfio_address_space_insert() vfio/common: Extract vIOMMU code from vfio_sync_dirty_bitmap() vfio/common: Move dirty tracking ranges update to helper vfio: Remove unused declarations from vfio-common.h vfio: Make vfio_devices_dma_logging_start() return bool memory: Remove IOMMU MR iommu_set_iova_range API hw/vfio: Remove memory_region_iommu_set_iova_ranges() call virtio-iommu: Remove the implementation of iommu_set_iova_range ... Signed-off-by: Richard Henderson <richard.henderson@linaro.org>
2024-06-24HostIOMMUDevice: Store the aliased bus and devfnEric Auger1-0/+2
Store the aliased bus and devfn in the HostIOMMUDevice. This will be useful to handle info that are iommu group specific and not device specific (such as reserved iova ranges). Signed-off-by: Eric Auger <eric.auger@redhat.com> Reviewed-by: Zhenzhong Duan <zhenzhong.duan@intel.com> Reviewed-by: Michael S. Tsirkin <mst@redhat.com>
2024-06-24HostIOMMUDevice: Introduce get_iova_ranges callbackEric Auger1-0/+8
Introduce a new HostIOMMUDevice callback that allows to retrieve the usable IOVA ranges. Implement this callback in the legacy VFIO and IOMMUFD VFIO host iommu devices. This relies on the VFIODevice agent's base container iova_ranges resource. Signed-off-by: Eric Auger <eric.auger@redhat.com> Reviewed-by: Zhenzhong Duan <zhenzhong.duan@intel.com> Reviewed-by: Michael S. Tsirkin <mst@redhat.com>
2024-06-24HostIOMMUDevice: Store the VFIO/VDPA agentEric Auger1-0/+1
Store the agent device (VFIO or VDPA) in the host IOMMU device. This will allow easy access to some of its resources. Signed-off-by: Eric Auger <eric.auger@redhat.com> Reviewed-by: Zhenzhong Duan <zhenzhong.duan@intel.com> Reviewed-by: Michael S. Tsirkin <mst@redhat.com>
2024-06-24backends/iommufd: Introduce helper function iommufd_backend_get_device_info()Zhenzhong Duan1-0/+3
Introduce a helper function iommufd_backend_get_device_info() to get host IOMMU related information through iommufd uAPI. Signed-off-by: Yi Liu <yi.l.liu@intel.com> Signed-off-by: Yi Sun <yi.y.sun@linux.intel.com> Signed-off-by: Zhenzhong Duan <zhenzhong.duan@intel.com> Reviewed-by: Eric Auger <eric.auger@redhat.com> Reviewed-by: Michael S. Tsirkin <mst@redhat.com>
2024-06-24backends/iommufd: Introduce TYPE_HOST_IOMMU_DEVICE_IOMMUFD[_VFIO] devicesZhenzhong Duan1-0/+16
TYPE_HOST_IOMMU_DEVICE_IOMMUFD represents a host IOMMU device under iommufd backend. It is abstract, because it is going to be derived into VFIO or VDPA type'd device. It will have its own .get_cap() implementation. TYPE_HOST_IOMMU_DEVICE_IOMMUFD_VFIO is a sub-class of TYPE_HOST_IOMMU_DEVICE_IOMMUFD, represents a VFIO type'd host IOMMU device under iommufd backend. It will be created during VFIO device attaching and passed to vIOMMU. It will have its own .realize() implementation. Opportunistically, add missed header to include/sysemu/iommufd.h. Suggested-by: Cédric Le Goater <clg@redhat.com> Signed-off-by: Yi Liu <yi.l.liu@intel.com> Signed-off-by: Zhenzhong Duan <zhenzhong.duan@intel.com> Reviewed-by: Eric Auger <eric.auger@redhat.com> Reviewed-by: Michael S. Tsirkin <mst@redhat.com>
2024-06-24backends/host_iommu_device: Introduce HostIOMMUDeviceCapsZhenzhong Duan1-0/+38
HostIOMMUDeviceCaps's elements map to the host IOMMU's capabilities. Different platform IOMMU can support different elements. Currently only two elements, type and aw_bits, type hints the host platform IOMMU type, i.e., INTEL vtd, ARM smmu, etc; aw_bits hints host IOMMU address width. Introduce .get_cap() handler to check if HOST_IOMMU_DEVICE_CAP_XXX is supported. Suggested-by: Cédric Le Goater <clg@redhat.com> Signed-off-by: Zhenzhong Duan <zhenzhong.duan@intel.com> Reviewed-by: Eric Auger <eric.auger@redhat.com> Reviewed-by: Michael S. Tsirkin <mst@redhat.com>
2024-06-24backends: Introduce HostIOMMUDevice abstractZhenzhong Duan1-0/+53
A HostIOMMUDevice is an abstraction for an assigned device that is protected by a physical IOMMU (aka host IOMMU). The userspace interaction with this physical IOMMU can be done either through the VFIO IOMMU type 1 legacy backend or the new iommufd backend. The assigned device can be a VFIO device or a VDPA device. The HostIOMMUDevice is needed to interact with the host IOMMU that protects the assigned device. It is especially useful when the device is also protected by a virtual IOMMU as this latter use the translation services of the physical IOMMU and is constrained by it. In that context the HostIOMMUDevice can be passed to the virtual IOMMU to collect physical IOMMU capabilities such as the supported address width. In the future, the virtual IOMMU will use the HostIOMMUDevice to program the guest page tables in the first translation stage of the physical IOMMU. Introduce .realize() to initialize HostIOMMUDevice further after instance init. Suggested-by: Cédric Le Goater <clg@redhat.com> Signed-off-by: Zhenzhong Duan <zhenzhong.duan@intel.com> Reviewed-by: Eric Auger <eric.auger@redhat.com> Reviewed-by: Michael S. Tsirkin <mst@redhat.com>
2024-06-24qtest: move qtest_{get, set}_virtual_clock to accel/qtest/qtest.cPierrick Bouvier1-3/+0
Signed-off-by: Pierrick Bouvier <pierrick.bouvier@linaro.org> Reviewed-by: Philippe Mathieu-Daudé <philmd@linaro.org> Signed-off-by: Alex Bennée <alex.bennee@linaro.org> Message-Id: <20240530220610.1245424-5-pierrick.bouvier@linaro.org> Message-Id: <20240620152220.2192768-8-alex.bennee@linaro.org>
2024-06-24qtest: use cpu interface in qtest_clock_warpAlex Bennée1-0/+1
This generalises the qtest_clock_warp code to use the AccelOps handlers for updating its own sense of time. This will make the next patch which moves the warp code closer to pure code motion. From: Alex Bennée <alex.bennee@linaro.org> Acked-by: Thomas Huth <thuth@redhat.com> Signed-off-by: Pierrick Bouvier <pierrick.bouvier@linaro.org> Message-Id: <20240530220610.1245424-3-pierrick.bouvier@linaro.org> Signed-off-by: Alex Bennée <alex.bennee@linaro.org> Message-Id: <20240620152220.2192768-6-alex.bennee@linaro.org>
2024-06-24sysemu: add set_virtual_time to accel opsAlex Bennée2-2/+19
We are about to remove direct calls to individual accelerators for this information and will need a central point for plugins to hook into time changes. Reviewed-by: Philippe Mathieu-Daudé <philmd@linaro.org> Signed-off-by: Pierrick Bouvier <pierrick.bouvier@linaro.org> Reviewed-by: Richard Henderson <richard.henderson@linaro.org> Message-Id: <20240530220610.1245424-2-pierrick.bouvier@linaro.org> Signed-off-by: Alex Bennée <alex.bennee@linaro.org> Message-Id: <20240620152220.2192768-5-alex.bennee@linaro.org>
2024-06-09xen: mapcache: Add support for grant mappingsEdgar E. Iglesias1-0/+1
Add a second mapcache for grant mappings. The mapcache for grants needs to work with XC_PAGE_SIZE granularity since we can't map larger ranges than what has been granted to us. Like with foreign mappings (xen_memory), machines using grants are expected to initialize the xen_grants MR and map it into their address-map accordingly. CC: Manos Pitsidianakis <manos.pitsidianakis@linaro.org> Signed-off-by: Edgar E. Iglesias <edgar.iglesias@amd.com> Reviewed-by: Stefano Stabellini <sstabellini@kernel.org>
2024-06-09xen: mapcache: Pass the ram_addr offset to xen_map_cache()Edgar E. Iglesias1-0/+2
Pass the ram_addr offset to xen_map_cache. This is in preparation for adding grant mappings that need to compute the address within the RAMBlock. No functional changes. Signed-off-by: Edgar E. Iglesias <edgar.iglesias@amd.com> Reviewed-by: David Hildenbrand <david@redhat.com> Reviewed-by: Stefano Stabellini <sstabellini@kernel.org> Reviewed-by: Philippe Mathieu-Daudé <philmd@linaro.org>
2024-06-08hvf: Makes assert_hvf_ok report failed expressionPhil Dennis-Jordan1-1/+4
When a macOS Hypervisor.framework call fails which is checked by assert_hvf_ok(), Qemu exits printing the error value, but not the location in the code, as regular assert() macro expansions would. This change turns assert_hvf_ok() into a macro similar to other assertions, which expands to a call to the corresponding _impl() function together with information about the expression that failed the assertion and its location in the code. Additionally, stringifying the numeric hv_return_t code is factored into a helper function that can be reused for diagnostics and debugging outside of assertions. Signed-off-by: Phil Dennis-Jordan <phil@philjordan.eu> Message-ID: <20240605112556.43193-8-phil@philjordan.eu> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2024-06-08hvf: Consistent types for vCPU handlesPhil Dennis-Jordan1-1/+3
macOS Hypervisor.framework uses different types for identifying vCPUs, hv_vcpu_t or hv_vcpuid_t, depending on host architecture. They are not just differently named typedefs for the same primitive type, but reference different-width integers. Instead of using an integer type and casting where necessary, this change introduces a typedef which resolves the active architecture’s hvf typedef. It also removes a now-unnecessary cast. Signed-off-by: Phil Dennis-Jordan <phil@philjordan.eu> Reviewed-by: Roman Bolshakov <roman@roolebo.dev> Tested-by: Roman Bolshakov <roman@roolebo.dev> Message-ID: <20240605112556.43193-4-phil@philjordan.eu> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
generated by cgit v1.1 at 2025-07-10 05:29:51 +0000