summary refs log tree commit diff stats
path: root/scripts/coverage/compare_gcov_json.py (unfollow)
Commit message (Collapse)AuthorFilesLines
2023-09-18ppc/xive: Fix uint32_t overflowCédric Le Goater1-1/+1
As reported by Coverity, "idx << xive->pc_shift" is evaluated using 32-bit arithmetic, and then used in a context expecting a "uint64_t". Add a uint64_t cast. Fixes: Coverity CID 1519049 Fixes: b68147b7a5bf ("ppc/xive: Add support for the PC MMIOs") Signed-off-by: Cédric Le Goater <clg@kaod.org> Reviewed-by: Philippe Mathieu-Daudé <philmd@linaro.org> Reviewed-by: Frederic Barrat <fbarrat@linux.ibm.com> Message-ID: <20230914154650.222111-1-clg@kaod.org> Signed-off-by: Daniel Henrique Barboza <danielhb413@gmail.com>
2023-09-18MAINTAINERS: Nick Piggin PPC maintainer, other PPC changesDaniel Henrique Barboza1-13/+7
Update all relevant PowerPC entries as follows: - Nick Piggin is promoted to Maintainer in all qemu-ppc subsystems. Nick has been a solid contributor for the last couple of years and has the required knowledge and motivation to drive the boat. - Greg Kurz is being removed from all qemu-ppc entries. Greg has moved to other areas of interest and will retire from qemu-ppc. Thanks Mr Kurz for all the years of service. - David Gibson was removed as 'Reviewer' from PowerPC TCG CPUs and PPC KVM CPUs. Change done per his request. - Daniel Barboza downgraded from 'Maintainer' to 'Reviewer' in sPAPR and PPC KVM CPUs. It has been a long since I last touched those areas and it's not justified to be kept as maintainer in them. - Cedric Le Goater and Daniel Barboza removed as 'Reviewer' in VOF. We don't have the required knowledge to justify it. - VOF support downgraded from 'Maintained' to 'Odd Fixes' since it better reflects the current state of the subsystem. Acked-by: Cédric Le Goater <clg@kaod.org> Acked-by: Greg Kurz <groug@kaod.org> Reviewed-by: Philippe Mathieu-Daudé <philmd@linaro.org> Reviewed-by: Alex Bennée <alex.bennee@linaro.org> Reviewed-by: Harsh Prateek Bora <harshpb@linux.ibm.com> Acked-by: David Gibson <david@gibson.dropbear.id.au> Acked-by: Nicholas Piggin <npiggin@gmail.com> Message-ID: <20230915110507.194762-1-danielhb413@gmail.com> Signed-off-by: Daniel Henrique Barboza <danielhb413@gmail.com>
2023-09-13tpm: fix crash when FD >= 1024 and unnecessary errors due to EINTRMarc-André Lureau1-9/+2
Replace select() with poll() to fix a crash when QEMU has a large number of FDs. Also use RETRY_ON_EINTR to avoid unnecessary errors due to EINTR. Cc: qemu-stable@nongnu.org Fixes: https://bugzilla.redhat.com/show_bug.cgi?id=2020133 Fixes: 56a3c24ffc ("tpm: Probe for connected TPM 1.2 or TPM 2") Signed-off-by: Marc-André Lureau <marcandre.lureau@redhat.com> Reviewed-by: Michael Tokarev <mjt@tls.msk.ru> Reviewed-by: Stefan Berger <stefanb@linux.ibm.com> Signed-off-by: Stefan Berger <stefanb@linux.ibm.com>
2023-09-13target/i386: Call accel-agnostic x86_cpu_get_supported_cpuid()Philippe Mathieu-Daudé1-16/+16
x86_cpu_get_supported_cpuid() is generic and handles the different accelerators. Use it instead of kvm_arch_get_supported_cpuid(). That fixes a link failure introduced by commit 3adce820cf ("target/i386: Remove unused KVM stubs") when QEMU is configured as: $ ./configure --cc=clang \ --target-list=x86_64-linux-user,x86_64-softmmu \ --enable-debug We were getting: [71/71] Linking target qemu-x86_64 FAILED: qemu-x86_64 /usr/bin/ld: libqemu-x86_64-linux-user.fa.p/target_i386_cpu.c.o: in function `cpu_x86_cpuid': cpu.c:(.text+0x1374): undefined reference to `kvm_arch_get_supported_cpuid' /usr/bin/ld: libqemu-x86_64-linux-user.fa.p/target_i386_cpu.c.o: in function `x86_cpu_filter_features': cpu.c:(.text+0x81c2): undefined reference to `kvm_arch_get_supported_cpuid' /usr/bin/ld: cpu.c:(.text+0x81da): undefined reference to `kvm_arch_get_supported_cpuid' /usr/bin/ld: cpu.c:(.text+0x81f2): undefined reference to `kvm_arch_get_supported_cpuid' /usr/bin/ld: cpu.c:(.text+0x820a): undefined reference to `kvm_arch_get_supported_cpuid' /usr/bin/ld: libqemu-x86_64-linux-user.fa.p/target_i386_cpu.c.o:cpu.c:(.text+0x8225): more undefined references to `kvm_arch_get_supported_cpuid' follow clang: error: linker command failed with exit code 1 (use -v to see invocation) ninja: build stopped: subcommand failed. For the record, this is because '--enable-debug' disables optimizations (CFLAGS=-O0). While at this (un)optimization level GCC eliminate the following dead code (CPP output of mentioned build): static void x86_cpu_get_supported_cpuid(uint32_t func, uint32_t index, uint32_t *eax, uint32_t *ebx, uint32_t *ecx, uint32_t *edx) { if ((0)) { *eax = kvm_arch_get_supported_cpuid(kvm_state, func, index, R_EAX); *ebx = kvm_arch_get_supported_cpuid(kvm_state, func, index, R_EBX); *ecx = kvm_arch_get_supported_cpuid(kvm_state, func, index, R_ECX); *edx = kvm_arch_get_supported_cpuid(kvm_state, func, index, R_EDX); } else if (0) { *eax = 0; *ebx = 0; *ecx = 0; *edx = 0; } else { *eax = 0; *ebx = 0; *ecx = 0; *edx = 0; } Clang does not (see commit 2140cfa51d "i386: Fix build by providing stub kvm_arch_get_supported_cpuid()"). Cc: qemu-stable@nongnu.org Fixes: 3adce820cf ("target/i386: Remove unused KVM stubs") Reported-by: Kevin Wolf <kwolf@redhat.com> Suggested-by: Paolo Bonzini <pbonzini@redhat.com> Signed-off-by: Philippe Mathieu-Daudé <philmd@linaro.org> Message-ID: <20230913093009.83520-4-philmd@linaro.org> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2023-09-13target/i386: Drop accel_uses_host_cpuid before x86_cpu_get_supported_cpuidPhilippe Mathieu-Daudé1-6/+4
x86_cpu_get_supported_cpuid() already checks for KVM/HVF accelerators, so it is not needed to manually check it via a call to accel_uses_host_cpuid() before calling it. Suggested-by: Paolo Bonzini <pbonzini@redhat.com> Signed-off-by: Philippe Mathieu-Daudé <philmd@linaro.org> Message-ID: <20230913093009.83520-3-philmd@linaro.org> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2023-09-13target/i386: Check kvm_hyperv_expand_features() return valuePhilippe Mathieu-Daudé1-2/+2
In case more code is added after the kvm_hyperv_expand_features() call, check its return value (since it can fail). Fixes: 071ce4b03b ("i386: expand Hyper-V features during CPU feature expansion time") Signed-off-by: Philippe Mathieu-Daudé <philmd@linaro.org> Message-ID: <20230913093009.83520-2-philmd@linaro.org> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2023-09-13meson: Fix targetos match for illumos and Solaris.Jonathan Perkin2-3/+3
qemu 8.1.0 breaks on illumos platforms due to _XOPEN_SOURCE and others no longer being set correctly, leading to breakage such as: https://us-central.manta.mnx.io/pkgsrc/public/reports/trunk/tools/20230908.1404/qemu-8.1.0/build.log This is a result of meson conversion which incorrectly matches against 'solaris' instead of 'sunos' for uname. First time submitting a patch here, hope I did it correctly. Thanks. Signed-off-by: Jonathan Perkin <jonathan@perkin.org.uk> Message-ID: <ZPtdxtum9UVPy58J@perkin.org.uk> Cc: qemu-stable@nongnu.org Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2023-09-12hw/nvme: Avoid dynamic stack allocationPeter Maydell1-1/+1
Instead of using a variable-length array in nvme_map_prp(), allocate on the stack with a g_autofree pointer. The codebase has very few VLAs, and if we can get rid of them all we can make the compiler error on new additions. This is a defensive measure against security bugs where an on-stack dynamic allocation isn't correctly size-checked (e.g. CVE-2021-3527). Signed-off-by: Peter Maydell <peter.maydell@linaro.org> Signed-off-by: Klaus Jensen <k.jensen@samsung.com>
2023-09-12hw/nvme: Use #define to avoid variable length arrayPhilippe Mathieu-Daudé1-1/+1
In nvme_map_sgl() we create an array segment[] whose size is the 'const int SEG_CHUNK_SIZE'. Since this is C, rather than C++, a "const int foo" is not a true constant, it's merely a variable with a constant value, and so semantically segment[] is a variable-length array. Switch SEG_CHUNK_SIZE to a #define so that we can make the segment[] array truly fixed-size, in the sense that it doesn't trigger the -Wvla warning. The codebase has very few VLAs, and if we can get rid of them all we can make the compiler error on new additions. This is a defensive measure against security bugs where an on-stack dynamic allocation isn't correctly size-checked (e.g. CVE-2021-3527). [PMM: rebased (function has moved file), expand commit message based on discussion from previous version of patch] Signed-off-by: Philippe Mathieu-Daudé <philmd@redhat.com> Signed-off-by: Peter Maydell <peter.maydell@linaro.org> Signed-off-by: Klaus Jensen <k.jensen@samsung.com>
2023-09-12tests/qtest/pflash: Clean up local variable shadowingPhilippe Mathieu-Daudé1-1/+1
Fix: tests/qtest/pflash-cfi02-test.c: In function ‘test_geometry’: tests/qtest/pflash-cfi02-test.c:409:22: warning: declaration of ‘byte_addr’ shadows a previous local [-Wshadow=compatible-local] 409 | uint64_t byte_addr = (uint64_t)i * c->sector_len[region]; | ^~~~~~~~~ tests/qtest/pflash-cfi02-test.c:342:14: note: shadowed declaration is here 342 | uint64_t byte_addr = 0; | ^~~~~~~~~ Signed-off-by: Philippe Mathieu-Daudé <philmd@linaro.org> Message-ID: <20230904162824.85385-4-philmd@linaro.org> Reviewed-by: Peter Maydell <peter.maydell@linaro.org> Signed-off-by: Thomas Huth <thuth@redhat.com>
2023-09-12kconfig: Add NVME to s390x machinesCédric Le Goater1-1/+1
We recently had issues with nvme devices on big endian platforms. Include their compilation on s390x to ease tests. Signed-off-by: Cédric Le Goater <clg@redhat.com> Message-ID: <20230828150148.120031-1-clg@kaod.org> Reviewed-by: Thomas Huth <thuth@redhat.com> Acked-by: Klaus Jensen <k.jensen@samsung.com> Signed-off-by: Thomas Huth <thuth@redhat.com>
2023-09-12target/s390x: AP-passthrough for PV guestsSteffen Eiden5-0/+79
Enabling AP-passthrough(AP-pt) for PV-guest by using the new CPU features for PV-AP-pt of KVM. As usual QEMU first checks which CPU features are available and then sets them if available and selected by user. An additional check is done to verify that PV-AP can only be enabled if "regular" AP-pt is enabled as well. Note that KVM itself does not enforce this restriction. Reviewed-by: Michael Mueller <mimu@linux.ibm.com> Reviewed-by: Thomas Huth <thuth@redhat.com> Signed-off-by: Steffen Eiden <seiden@linux.ibm.com> Message-ID: <20230823142219.1046522-6-seiden@linux.ibm.com> Signed-off-by: Thomas Huth <thuth@redhat.com>
2023-09-12target/s390x/kvm: Refactor AP functionalitiesSteffen Eiden1-7/+17
kvm_s390_set_attr() is a misleading name as it only sets attributes for the KVM_S390_VM_CRYPTO group. Therefore, rename it to kvm_s390_set_crypto_attr(). Add new functions ap_available() and ap_enabled() to avoid code duplication later. Reviewed-by: Thomas Huth <thuth@redhat.com> Reviewed-by: Michael Mueller <mimu@linux.ibm.com> Signed-off-by: Steffen Eiden <seiden@linux.ibm.com> Message-ID: <20230823142219.1046522-5-seiden@linux.ibm.com> Signed-off-by: Thomas Huth <thuth@redhat.com>
2023-09-12linux-headers: Update to Linux v6.6-rc1Thomas Huth23-16/+351
This update contains the required header changes for the "target/s390x: AP-passthrough for PV guests" patch from Steffen Eiden. Message-ID: <20230912093432.180041-1-thuth@redhat.com> Signed-off-by: Thomas Huth <thuth@redhat.com>
2023-09-12s390x: do a subsystem reset before the unprotect on rebootJanosch Frank1-0/+10
Bound APQNs have to be reset before tearing down the secure config via s390_machine_unprotect(). Otherwise the Ultravisor will return a error code. So let's do a subsystem_reset() which includes a AP reset before the unprotect call. We'll do a full device_reset() afterwards which will reset some devices twice. That's ok since we can't move the device_reset() before the unprotect as it includes a CPU clear reset which the Ultravisor does not expect at that point in time. Signed-off-by: Janosch Frank <frankja@linux.ibm.com> Message-ID: <20230901114851.154357-1-frankja@linux.ibm.com> Tested-by: Viktor Mihajlovski <mihajlov@linux.ibm.com> Acked-by: Christian Borntraeger <borntraeger@linux.ibm.com> Signed-off-by: Thomas Huth <thuth@redhat.com>
2023-09-12s390x/ap: fix missing subsystem reset registrationJanosch Frank1-0/+1
A subsystem reset contains a reset of AP resources which has been missing. Adding the AP bridge to the list of device types that need reset fixes this issue. Reviewed-by: Jason J. Herne <jjherne@linux.ibm.com> Reviewed-by: Tony Krowiak <akrowiak@linux.ibm.com> Signed-off-by: Janosch Frank <frankja@linux.ibm.com> Fixes: a51b3153 ("s390x/ap: base Adjunct Processor (AP) object model") Message-ID: <20230823142219.1046522-2-seiden@linux.ibm.com> Signed-off-by: Thomas Huth <thuth@redhat.com>
2023-09-12ui: add precondition for dpy_get_ui_info()Marc-André Lureau2-2/+4
Ensure that it only get called when dpy_ui_info_supported(). The function should always return a result. There should be a non-null console or active_console. Modify the argument to be const as well. Signed-off-by: Marc-André Lureau <marcandre.lureau@redhat.com> Reviewed-by: Albert Esteve <aesteve@redhat.com>
2023-09-12ui: fix crash when there are no active_consoleMarc-André Lureau1-0/+3
Thread 1 "qemu-system-x86" received signal SIGSEGV, Segmentation fault. 0x0000555555888630 in dpy_ui_info_supported (con=0x0) at ../ui/console.c:812 812 return con->hw_ops->ui_info != NULL; (gdb) bt #0 0x0000555555888630 in dpy_ui_info_supported (con=0x0) at ../ui/console.c:812 #1 0x00005555558a44b1 in protocol_client_msg (vs=0x5555578c76c0, data=0x5555581e93f0 <incomplete sequence \373>, len=24) at ../ui/vnc.c:2585 #2 0x00005555558a19ac in vnc_client_read (vs=0x5555578c76c0) at ../ui/vnc.c:1607 #3 0x00005555558a1ac2 in vnc_client_io (ioc=0x5555581eb0e0, condition=G_IO_IN, opaque=0x5555578c76c0) at ../ui/vnc.c:1635 Fixes: https://issues.redhat.com/browse/RHEL-2600 Signed-off-by: Marc-André Lureau <marcandre.lureau@redhat.com> Reviewed-by: Albert Esteve <aesteve@redhat.com>
2023-09-12virtio-gpu/win32: set the destroy function on loadMarc-André Lureau1-1/+3
Don't forget to unmap the resource memory. Fixes: commit 9462ff469 ("virtio-gpu/win32: allocate shareable 2d resources/images") Signed-off-by: Marc-André Lureau <marcandre.lureau@redhat.com>
2023-09-12ui/console: move DisplaySurface to its own headerMarc-André Lureau2-83/+96
Mostly for readability reasons. Signed-off-by: Marc-André Lureau <marcandre.lureau@redhat.com> Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>
2023-09-12ui/vc: split off the VC part from console.cMarc-André Lureau4-1093/+1126
Move common declarations to console-priv.h, and add a new unit console-vc.c which will handle VC/chardev rendering, when pixman is available. (if necessary, the move could be done chunk by chunks) Signed-off-by: Marc-André Lureau <marcandre.lureau@redhat.com> Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>
2023-09-12ui/vc: preliminary QemuTextConsole changes before splitMarc-André Lureau1-17/+35
Those changes will help to split console.c unit in the following commit. Signed-off-by: Marc-André Lureau <marcandre.lureau@redhat.com> Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>
2023-09-12ui/console: remove redundant format fieldMarc-André Lureau6-15/+12
It's already part of PIXMAN image. Signed-off-by: Marc-André Lureau <marcandre.lureau@redhat.com> Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>
2023-09-12ui/vc: rename kbd_put to qemu_text_console functionsMarc-André Lureau8-43/+43
They are QemuTextConsole functions, let's make it clear. Signed-off-by: Marc-André Lureau <marcandre.lureau@redhat.com> Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>
2023-09-12ui/vc: remove kbd_put_keysym() and update function callsMarc-André Lureau5-37/+36
The function calls to `kbd_put_keysym` have been updated to now call `kbd_put_keysym_console` with a NULL console parameter. Like most console functions, NULL argument is now for the active console. This will allow to rename the text console functions in a consistent manner. Signed-off-by: Marc-André Lureau <marcandre.lureau@redhat.com> Reviewed-by: Akihiko Odaki <akihiko.odaki@daynix.com>
2023-09-12vmmouse: use explicit codeMarc-André Lureau1-2/+11
It's weird to shift x & y without obvious reason. Let's make this more explicit and future-proof. Signed-off-by: Marc-André Lureau <marcandre.lureau@redhat.com>
2023-09-12vmmouse: replace DPRINTF with tracingMarc-André Lureau2-15/+24
Signed-off-by: Marc-André Lureau <marcandre.lureau@redhat.com> Reviewed-by: Philippe Mathieu-Daudé <philmd@linaro.org>
2023-09-12vhost-user-gpu: support dmabuf modifiersErico Nunes1-1/+16
When the backend sends VHOST_USER_GPU_DMABUF_SCANOUT2, handle it by getting the modifiers information which is now available. Signed-off-by: Erico Nunes <ernunes@redhat.com> Reviewed-by: Marc-André Lureau <marcandre.lureau@redhat.com> Reviewed-by: Sergio Lopez <slp@redhat.com> Message-Id: <20230714153900.475857-4-ernunes@redhat.com>
2023-09-12contrib/vhost-user-gpu: add support for sending dmabuf modifiersErico Nunes3-4/+61
virglrenderer recently added virgl_renderer_resource_get_info_ext as a new api, which gets resource information, including dmabuf modifiers. We have to support dmabuf modifiers since the driver may choose to allocate buffers with these modifiers for efficiency, and importing buffers without modifiers information may result in completely broken rendering. Signed-off-by: Erico Nunes <ernunes@redhat.com> Reviewed-by: Marc-André Lureau <marcandre.lureau@redhat.com> Reviewed-by: Sergio Lopez <slp@redhat.com> Message-Id: <20230714153900.475857-3-ernunes@redhat.com>
2023-09-12docs: vhost-user-gpu: add protocol changes for dmabuf modifiersErico Nunes1-1/+25
VHOST_USER_GPU_DMABUF_SCANOUT2 is defined as a message with all the contents of VHOST_USER_GPU_DMABUF_SCANOUT plus the dmabuf modifiers which were ommitted. The VHOST_USER_GPU_PROTOCOL_F_DMABUF2 protocol feature is defined as a way to check whether this new message is supported or not. Signed-off-by: Erico Nunes <ernunes@redhat.com> Reviewed-by: Marc-André Lureau <marcandre.lureau@redhat.com> Reviewed-by: Sergio Lopez <slp@redhat.com> Message-Id: <20230714153900.475857-2-ernunes@redhat.com>
2023-09-11vfio/common: Separate vfio-pci rangesJoao Martins2-12/+61
QEMU computes the DMA logging ranges for two predefined ranges: 32-bit and 64-bit. In the OVMF case, when the dynamic MMIO window is enabled, QEMU includes in the 64-bit range the RAM regions at the lower part and vfio-pci device RAM regions which are at the top of the address space. This range contains a large gap and the size can be bigger than the dirty tracking HW limits of some devices (MLX5 has a 2^42 limit). To avoid such large ranges, introduce a new PCI range covering the vfio-pci device RAM regions, this only if the addresses are above 4GB to avoid breaking potential SeaBIOS guests. [ clg: - wrote commit log - fixed overlapping 32-bit and PCI ranges when using SeaBIOS ] Signed-off-by: Joao Martins <joao.m.martins@oracle.com> Signed-off-by: Cédric Le Goater <clg@redhat.com> Fixes: 5255bbf4ec16 ("vfio/common: Add device dirty page tracking start/stop") Signed-off-by: Cédric Le Goater <clg@redhat.com>
2023-09-11vfio/migration: Block VFIO migration with background snapshotAvihai Horon1-1/+10
Background snapshot allows creating a snapshot of the VM while it's running and keeping it small by not including dirty RAM pages. The way it works is by first stopping the VM, saving the non-iterable devices' state and then starting the VM and saving the RAM while write protecting it with UFFD. The resulting snapshot represents the VM state at snapshot start. VFIO migration is not compatible with background snapshot. First of all, VFIO device state is not even saved in background snapshot because only non-iterable device state is saved. But even if it was saved, after starting the VM, a VFIO device could dirty pages without it being detected by UFFD write protection. This would corrupt the snapshot, as the RAM in it would not represent the RAM at snapshot start. To prevent this, block VFIO migration with background snapshot. Signed-off-by: Avihai Horon <avihaih@nvidia.com> Reviewed-by: Peter Xu <peterx@redhat.com> Signed-off-by: Cédric Le Goater <clg@redhat.com>
2023-09-11vfio/migration: Block VFIO migration with postcopy migrationAvihai Horon1-0/+22
VFIO migration is not compatible with postcopy migration. A VFIO device in the destination can't handle page faults for pages that have not been sent yet. Doing such migration will cause the VM to crash in the destination: qemu-system-x86_64: VFIO_MAP_DMA failed: Bad address qemu-system-x86_64: vfio_dma_map(0x55a28c7659d0, 0xc0000, 0xb000, 0x7f1b11a00000) = -14 (Bad address) qemu: hardware error: vfio: DMA mapping failed, unable to continue To prevent this, block VFIO migration with postcopy migration. Reported-by: Yanghang Liu <yanghliu@redhat.com> Signed-off-by: Avihai Horon <avihaih@nvidia.com> Tested-by: Yanghang Liu <yanghliu@redhat.com> Reviewed-by: Peter Xu <peterx@redhat.com> Signed-off-by: Cédric Le Goater <clg@redhat.com>
2023-09-11migration: Add .save_prepare() handler to struct SaveVMHandlersAvihai Horon5-4/+48
Add a new .save_prepare() handler to struct SaveVMHandlers. This handler is called early, even before migration starts, and can be used by devices to perform early checks. Refactor migrate_init() to be able to return errors and call .save_prepare() from there. Suggested-by: Peter Xu <peterx@redhat.com> Signed-off-by: Avihai Horon <avihaih@nvidia.com> Reviewed-by: Peter Xu <peterx@redhat.com> Reviewed-by: Cédric Le Goater <clg@redhat.com> Signed-off-by: Cédric Le Goater <clg@redhat.com>
2023-09-11migration: Move more initializations to migrate_init()Avihai Horon2-10/+7
Initialization of mig_stats, compression_counters and VFIO bytes transferred is hard-coded in migration code path and snapshot code path. Make the code cleaner by initializing them in migrate_init(). Suggested-by: Cédric Le Goater <clg@redhat.com> Signed-off-by: Avihai Horon <avihaih@nvidia.com> Reviewed-by: Cédric Le Goater <clg@redhat.com> Signed-off-by: Cédric Le Goater <clg@redhat.com>
2023-09-11vfio/migration: Fail adding device with enable-migration=on and existing blockerAvihai Horon1-2/+5
If a device with enable-migration=on is added and it causes a migration blocker, adding the device should fail with a proper error. This is not the case with multiple device migration blocker when the blocker already exists. If the blocker already exists and a device with enable-migration=on is added which causes a migration blocker, adding the device will succeed. Fix it by failing adding the device in such case. Fixes: 8bbcb64a71d8 ("vfio/migration: Make VFIO migration non-experimental") Signed-off-by: Avihai Horon <avihaih@nvidia.com> Reviewed-by: Cédric Le Goater <clg@redhat.com> Signed-off-by: Cédric Le Goater <clg@redhat.com>
2023-09-11migration: Add migration prefix to functions in target.cAvihai Horon4-10/+10
The functions in target.c are not static, yet they don't have a proper migration prefix. Add such prefix. Signed-off-by: Avihai Horon <avihaih@nvidia.com> Reviewed-by: Cédric Le Goater <clg@redhat.com> Signed-off-by: Cédric Le Goater <clg@redhat.com>
2023-09-11vfio/migration: Allow migration of multiple P2P supporting devicesAvihai Horon1-8/+18
Now that P2P support has been added to VFIO migration, allow migration of multiple devices if all of them support P2P migration. Single device migration is allowed regardless of P2P migration support. Signed-off-by: Avihai Horon <avihaih@nvidia.com> Signed-off-by: Joao Martins <joao.m.martins@oracle.com> Reviewed-by: Cédric Le Goater <clg@redhat.com> Tested-by: YangHang Liu <yanghliu@redhat.com> Signed-off-by: Cédric Le Goater <clg@redhat.com>
2023-09-11vfio/migration: Add P2P support for VFIO migrationAvihai Horon4-41/+105
VFIO migration uAPI defines an optional intermediate P2P quiescent state. While in the P2P quiescent state, P2P DMA transactions cannot be initiated by the device, but the device can respond to incoming ones. Additionally, all outstanding P2P transactions are guaranteed to have been completed by the time the device enters this state. The purpose of this state is to support migration of multiple devices that might do P2P transactions between themselves. Add support for P2P migration by transitioning all the devices to the P2P quiescent state before stopping or starting the devices. Use the new VMChangeStateHandler prepare_cb to achieve that behavior. This will allow migration of multiple VFIO devices if all of them support P2P migration. Signed-off-by: Avihai Horon <avihaih@nvidia.com> Tested-by: YangHang Liu <yanghliu@redhat.com> Reviewed-by: Cédric Le Goater <clg@redhat.com> Signed-off-by: Cédric Le Goater <clg@redhat.com>
2023-09-11vfio/migration: Refactor PRE_COPY and RUNNING state checksJoao Martins3-10/+24
Move the PRE_COPY and RUNNING state checks to helper functions. This is in preparation for adding P2P VFIO migration support, where these helpers will also test for PRE_COPY_P2P and RUNNING_P2P states. Signed-off-by: Joao Martins <joao.m.martins@oracle.com> Signed-off-by: Avihai Horon <avihaih@nvidia.com> Reviewed-by: Cédric Le Goater <clg@redhat.com> Tested-by: YangHang Liu <yanghliu@redhat.com> Signed-off-by: Cédric Le Goater <clg@redhat.com>
2023-09-11qdev: Add qdev_add_vm_change_state_handler_full()Avihai Horon2-1/+16
Add qdev_add_vm_change_state_handler_full() variant that allows setting a prepare callback in addition to the main callback. This will facilitate adding P2P support for VFIO migration in the following patches. Signed-off-by: Avihai Horon <avihaih@nvidia.com> Signed-off-by: Joao Martins <joao.m.martins@oracle.com> Reviewed-by: Cédric Le Goater <clg@redhat.com> Tested-by: YangHang Liu <yanghliu@redhat.com> Signed-off-by: Cédric Le Goater <clg@redhat.com>
2023-09-11sysemu: Add prepare callback to struct VMChangeStateEntryAvihai Horon2-0/+44
Add prepare callback to struct VMChangeStateEntry. The prepare callback is optional and can be set by the new function qemu_add_vm_change_state_handler_prio_full() that allows setting this callback in addition to the main callback. The prepare callbacks and main callbacks are called in two separate phases: First all prepare callbacks are called and only then all main callbacks are called. The purpose of the new prepare callback is to allow all devices to run a preliminary task before calling the devices' main callbacks. This will facilitate adding P2P support for VFIO migration where all VFIO devices need to be put in an intermediate P2P quiescent state before being stopped or started by the main callback. Signed-off-by: Avihai Horon <avihaih@nvidia.com> Reviewed-by: Cédric Le Goater <clg@redhat.com> Tested-by: YangHang Liu <yanghliu@redhat.com> Signed-off-by: Cédric Le Goater <clg@redhat.com>
2023-09-11vfio/migration: Move from STOP_COPY to STOP in vfio_save_cleanup()Avihai Horon1-6/+13
Changing the device state from STOP_COPY to STOP can take time as the device may need to free resources and do other operations as part of the transition. Currently, this is done in vfio_save_complete_precopy() and therefore it is counted in the migration downtime. To avoid this, change the device state from STOP_COPY to STOP in vfio_save_cleanup(), which is called after migration has completed and thus is not part of migration downtime. Signed-off-by: Avihai Horon <avihaih@nvidia.com> Tested-by: YangHang Liu <yanghliu@redhat.com> Signed-off-by: Cédric Le Goater <clg@redhat.com>
2023-09-11target/riscv: don't read CSR in riscv_csrrw_do64Nikita Shubin1-9/+15
As per ISA: "For CSRRWI, if rd=x0, then the instruction shall not read the CSR and shall not cause any of the side effects that might occur on a CSR read." trans_csrrwi() and trans_csrrw() call do_csrw() if rd=x0, do_csrw() calls riscv_csrrw_do64(), via helper_csrw() passing NULL as *ret_value. Signed-off-by: Nikita Shubin <n.shubin@yadro.com> Reviewed-by: Alistair Francis <alistair.francis@wdc.com> Message-ID: <20230808090914.17634-1-nikita.shubin@maquefel.me> Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
2023-09-11target/riscv: Align the AIA model to v1.0 ratified specTommy Wu1-2/+5
According to the new spec, when vsiselect has a reserved value, attempts from M-mode or HS-mode to access vsireg, or from VS-mode to access sireg, should preferably raise an illegal instruction exception. Signed-off-by: Tommy Wu <tommy.wu@sifive.com> Reviewed-by: Frank Chang <frank.chang@sifive.com> Message-ID: <20230816061647.600672-1-tommy.wu@sifive.com> Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
2023-09-11target/riscv/pmp.c: respect mseccfg.RLB for pmpaddrX changesLeon Schuermann1-0/+4
When the rule-lock bypass (RLB) bit is set in the mseccfg CSR, the PMP configuration lock bits must not apply. While this behavior is implemented for the pmpcfgX CSRs, this bit is not respected for changes to the pmpaddrX CSRs. This patch ensures that pmpaddrX CSR writes work even on locked regions when the global rule-lock bypass is enabled. Signed-off-by: Leon Schuermann <leons@opentitan.org> Reviewed-by: Mayuresh Chitale <mchitale@ventanamicro.com> Reviewed-by: Alistair Francis <alistair.francis@wdc.com> Message-ID: <20230829215046.1430463-1-leon@is.currently.online> Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
2023-09-11target/riscv: Allocate itrigger timers only onceAkihiko Odaki3-5/+21
riscv_trigger_init() had been called on reset events that can happen several times for a CPU and it allocated timers for itrigger. If old timers were present, they were simply overwritten by the new timers, resulting in a memory leak. Divide riscv_trigger_init() into two functions, namely riscv_trigger_realize() and riscv_trigger_reset() and call them in appropriate timing. The timer allocation will happen only once for a CPU in riscv_trigger_realize(). Fixes: 5a4ae64cac ("target/riscv: Add itrigger support when icount is enabled") Signed-off-by: Akihiko Odaki <akihiko.odaki@daynix.com> Reviewed-by: Philippe Mathieu-Daudé <philmd@linaro.org> Reviewed-by: LIU Zhiwei <zhiwei_liu@linux.alibaba.com> Reviewed-by: Alistair Francis <alistair.francis@wdc.com> Message-ID: <20230818034059.9146-1-akihiko.odaki@daynix.com> Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
2023-09-11target/riscv: Use accelerated helper for AES64KS1IArd Biesheuvel1-12/+5
Use the accelerated SubBytes/ShiftRows/AddRoundKey AES helper to implement the first half of the key schedule derivation. This does not actually involve shifting rows, so clone the same value into all four columns of the AES vector to counter that operation. Cc: Richard Henderson <richard.henderson@linaro.org> Cc: Philippe Mathieu-Daudé <philmd@linaro.org> Cc: Palmer Dabbelt <palmer@dabbelt.com> Cc: Alistair Francis <alistair.francis@wdc.com> Signed-off-by: Ard Biesheuvel <ardb@kernel.org> Reviewed-by: Philippe Mathieu-Daudé <philmd@linaro.org> Reviewed-by: Richard Henderson <richard.henderson@linaro.org> Message-ID: <20230831154118.138727-1-ardb@kernel.org> Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
2023-09-11linux-user/riscv: Add new extensions to hwprobeRobbin Ehn1-1/+13
This patch adds the new extensions in linux 6.5 to the hwprobe syscall. And fixes RVC check to OR with correct value. The previous variable contains 0 therefore it did work. Signed-off-by: Robbin Ehn <rehn@rivosinc.com> Acked-by: Richard Henderson <richard.henderson@linaro.org> Acked-by: Alistair Francis <alistair.francis@wdc.com> Message-ID: <bc82203b72d7efb30f1b4a8f9eb3d94699799dc8.camel@rivosinc.com> Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
2023-09-11hw/intc/riscv_aplic.c fix non-KVM --enable-debug buildDaniel Henrique Barboza3-6/+8
Commit 6df0b37e2ab breaks a --enable-debug build in a non-KVM environment with the following error: /usr/bin/ld: libqemu-riscv64-softmmu.fa.p/hw_intc_riscv_aplic.c.o: in function `riscv_kvm_aplic_request': ./qemu/build/../hw/intc/riscv_aplic.c:486: undefined reference to `kvm_set_irq' collect2: error: ld returned 1 exit status This happens because the debug build will poke into the 'if (is_kvm_aia(aplic->msimode))' block and fail to find a reference to the KVM only function riscv_kvm_aplic_request(). There are multiple solutions to fix this. We'll go with the same solution from the previous patch, i.e. add a kvm_enabled() conditional to filter out the block. But there's a catch: riscv_kvm_aplic_request() is a local function that would end up being used if the compiler crops the block, and this won't work. Quoting Richard Henderson's explanation in [1]: "(...) the compiler won't eliminate entire unused functions with -O0" We'll solve it by moving riscv_kvm_aplic_request() to kvm.c and add its declaration in kvm_riscv.h, where all other KVM specific public functions are already declared. Other archs handles KVM specific code in this manner and we expect to do the same from now on. [1] https://lore.kernel.org/qemu-riscv/d2f1ad02-eb03-138f-9d08-db676deeed05@linaro.org/ Signed-off-by: Daniel Henrique Barboza <dbarboza@ventanamicro.com> Reviewed-by: Andrew Jones <ajones@ventanamicro.com> Reviewed-by: Philippe Mathieu-Daudé <philmd@linaro.org> Reviewed-by: Richard Henderson <richard.henderson@linaro.org> Message-ID: <20230830133503.711138-3-dbarboza@ventanamicro.com> Signed-off-by: Alistair Francis <alistair.francis@wdc.com>