Fiona Ebner [Fri, 23 May 2025 07:02:11 +0000 (09:02 +0200)]
hw/core/qdev-properties-system: Add missing return in set_drive_helper()
Currently, changing the 'drive' property of e.g. a scsi-hd object will
result in an assertion failure if the aio context of the block node
it's replaced with doesn't match the current aio context:
The problematic scenario is already detected, but a 'return' statement
was missing.
Cc: qemu-stable@nongnu.org Fixes: d1a58c176a ("qdev: allow setting drive property for realized device") Signed-off-by: Fiona Ebner <f.ebner@proxmox.com>
Message-ID: <20250523070211.280498-1-f.ebner@proxmox.com> Reviewed-by: Daniel P. Berrangé <berrange@redhat.com> Reviewed-by: Kevin Wolf <kwolf@redhat.com> Signed-off-by: Kevin Wolf <kwolf@redhat.com>
(cherry picked from commit eef2dd03f948a512499775043bdc0c5c88d8a2dd) Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>
Stefan Hajnoczi [Thu, 29 May 2025 20:31:47 +0000 (16:31 -0400)]
iotests: fix 240
Commit 2e8e18c2e463 ("virtio-scsi: add iothread-vq-mapping parameter")
removed the limitation that virtio-scsi devices must successfully set
the AioContext on their BlockBackends. This was made possible thanks to
the QEMU multi-queue block layer.
This change broke qemu-iotests 240, which checks that adding a
virtio-scsi device with a drive that is already in another AioContext
will fail.
Update the test to take the relaxed behavior into account. I considered
removing this test case entirely, but the code coverage still seems
valuable.
Fixes: 2e8e18c2e463 ("virtio-scsi: add iothread-vq-mapping parameter") Reported-by: Thomas Huth <thuth@redhat.com> Signed-off-by: Stefan Hajnoczi <stefanha@redhat.com> Reviewed-by: Eric Blake <eblake@redhat.com> Tested-by: Eric Blake <eblake@redhat.com>
Message-ID: <20250529203147.180338-1-stefanha@redhat.com> Reviewed-by: Kevin Wolf <kwolf@redhat.com> Signed-off-by: Kevin Wolf <kwolf@redhat.com>
(cherry picked from commit 2e887187454e57d04522099d4f04d17137d6e05c) Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>
Volker Rümelin [Thu, 15 May 2025 05:44:26 +0000 (07:44 +0200)]
hw/audio/asc: fix SIGSEGV in asc_realize()
AUD_open_out() may fail and return NULL. This may then lead to
a segmentation fault in memset() below. The memset() behaviour
is undefined if the pointer to the destination object is a null
pointer.
Add the missing error handling code.
Reviewed-by: Marc-André Lureau <marcandre.lureau@redhat.com> Signed-off-by: Volker Rümelin <vr_qemu@t-online.de> Reviewed-by: Mark Cave-Ayland <mark.cave-ayland@ilande.co.uk>
Message-Id: <20250515054429.7385-4-vr_qemu@t-online.de>
(cherry picked from commit d009f26a54f573468be721590a19350c224bc730) Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>
Volker Rümelin [Thu, 15 May 2025 05:44:25 +0000 (07:44 +0200)]
audio: fix size calculation in AUD_get_buffer_size_out()
The buffer size calculated by AUD_get_buffer_size_out() is often
incorrect. sw->hw->samples * sw->hw->info.bytes_per_frame is the
size of the mixing engine buffer in audio frames multiplied by
the size of one frame of the audio backend. Due to resampling or
format conversion, the size of the frontend buffer can differ
significantly.
Return the correct buffer size when the mixing engine is used.
Reviewed-by: Marc-André Lureau <marcandre.lureau@redhat.com> Signed-off-by: Volker Rümelin <vr_qemu@t-online.de>
Message-Id: <20250515054429.7385-3-vr_qemu@t-online.de>
(cherry picked from commit ccb4fec0e5f233cb61a83b3af59ae11716ea06c0) Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>
Volker Rümelin [Thu, 15 May 2025 05:44:24 +0000 (07:44 +0200)]
audio: fix SIGSEGV in AUD_get_buffer_size_out()
As far as the emulated audio devices are concerned the pointer
returned by AUD_open_out() is an opaque handle. This includes
the NULL pointer. In this case, AUD_get_buffer_size_out() should
return a sensible buffer size instead of triggering a segmentation
fault. All other public AUD_*_out() and audio_*_out() functions
handle this case.
Reviewed-by: Marc-André Lureau <marcandre.lureau@redhat.com> Signed-off-by: Volker Rümelin <vr_qemu@t-online.de>
Message-Id: <20250515054429.7385-2-vr_qemu@t-online.de>
(cherry picked from commit 5ddd6c8dc849b4af44bd06840c9133d64e62c27c) Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>
Vasant Hegde [Fri, 16 May 2025 10:05:35 +0000 (15:35 +0530)]
hw/i386/amd_iommu: Fix xtsup when vcpus < 255
If vCPUs > 255 then x86 common code (x86_cpus_init()) call kvm_enable_x2apic().
But if vCPUs <= 255 then the common code won't calls kvm_enable_x2apic().
This is because commit 8c6619f3e692 ("hw/i386/amd_iommu: Simplify non-KVM
checks on XTSup feature") removed the call to kvm_enable_x2apic when xtsup
is "on", which break things when guest is booted with x2apic mode and
there are <= 255 vCPUs.
Fix this by adding back kvm_enable_x2apic() call when xtsup=on.
Sairaj Kodilkar [Fri, 16 May 2025 10:05:34 +0000 (15:35 +0530)]
hw/i386/amd_iommu: Fix device setup failure when PT is on.
Commit c1f46999ef506 ("amd_iommu: Add support for pass though mode")
introduces the support for "pt" flag by enabling nodma memory when
"pt=off". This allowed VFIO devices to successfully register notifiers
by using nodma region.
But, This also broke things when guest is booted with the iommu=nopt
because, devices bypass the IOMMU and use untranslated addresses (IOVA) to
perform DMA reads/writes to the nodma memory region, ultimately resulting in
a failure to setup the devices in the guest.
Fix the above issue by always enabling the amdvi_dev_as->iommu memory region.
But this will once again cause VFIO devices to fail while registering the
notifiers with AMD IOMMU memory region.
Fixes: c1f46999ef506 ("amd_iommu: Add support for pass though mode") Signed-off-by: Sairaj Kodilkar <sarunkod@amd.com> Reviewed-by: Vasant Hegde <vasant.hegde@amd.com>
Message-Id: <20250516100535.4980-2-sarunkod@amd.com> Fixes: c1f46999ef506 ("amd_iommu: Add support for pass though mode") Signed-off-by: Sairaj Kodilkar <sarunkod@amd.com> Reviewed-by: Vasant Hegde <vasant.hegde@amd.com>
(cherry picked from commit 31753d5a336fbb4e9246397f4b90b6f611f27f22) Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>
Bernhard Beschow [Mon, 26 May 2025 20:38:20 +0000 (22:38 +0200)]
hw/i386/pc_piix: Fix RTC ISA IRQ wiring of isapc machine
Commit 56b1f50e3c10 ("hw/i386/pc: Wire RTC ISA IRQs in south bridges")
attempted to refactor RTC IRQ wiring which was previously done in
pc_basic_device_init() but forgot about the isapc machine. Fix this by
wiring in the code section dedicated exclusively to the isapc machine.
Resolves: https://gitlab.com/qemu-project/qemu/-/issues/2961 Fixes: 56b1f50e3c10 ("hw/i386/pc: Wire RTC ISA IRQs in south bridges")
cc: qemu-stable Signed-off-by: Bernhard Beschow <shentey@gmail.com> Reviewed-by: Mark Cave-Ayland <mark.caveayland@nutanix.com>
Message-Id: <20250526203820.1853-1-shentey@gmail.com> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
(cherry picked from commit 0b006153b7ec66505cb2d231235aa19ca5d2ce37) Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>
Huaitong Han [Thu, 22 May 2025 10:05:48 +0000 (18:05 +0800)]
vhost: Don't set vring call if guest notifier is unused
The vring call fd is set even when the guest does not use MSI-X (e.g., in the
case of virtio PMD), leading to unnecessary CPU overhead for processing
interrupts.
The commit 96a3d98d2c("vhost: don't set vring call if no vector") optimized the
case where MSI-X is enabled but the queue vector is unset. However, there's an
additional case where the guest uses INTx and the INTx_DISABLED bit in the PCI
config is set, meaning that no interrupt notifier will actually be used.
In such cases, the vring call fd should also be cleared to avoid redundant
interrupt handling.
Fixes: 96a3d98d2c("vhost: don't set vring call if no vector") Reported-by: Zhiyuan Yuan <yuanzhiyuan@chinatelecom.cn> Signed-off-by: Jidong Xia <xiajd@chinatelecom.cn> Signed-off-by: Huaitong Han <hanht2@chinatelecom.cn>
Message-Id: <20250522100548.212740-1-hanht2@chinatelecom.cn> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
(cherry picked from commit a9403bfcd93025df7b1924d0cf34fbc408955b33) Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>
ui/vnc: fix tight palette pixel encoding for 8/16-bpp formats
When sending a tight rectangle with the palette filter, if the client
format was 8/16bpp, the colours on big endian hosts are not set as
we're sending the wrong bytes. We must first cast the 32-bit colour
to a 16/8-bit value, and then send the result.
Reviewed-by: Philippe Mathieu-Daudé <philmd@linaro.org> Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
(cherry picked from commit 63d320909220a90647c484263ae5e2f26eb54587) Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>
ui/vnc: take account of client byte order in pixman format
The set_pixel_conversion() method is responsible for determining whether
the VNC client pixel format matches the server format, and thus whether
we can use the fast path "copy" impl for sending pixels, or must use
the generic impl with bit swizzling.
The VNC server format is set at build time to VNC_SERVER_FB_FORMAT,
which corresponds to PIXMAN_x8r8g8b8.
The qemu_pixman_get_format() method is then responsible for converting
the VNC pixel format into a pixman format.
The VNC client pixel shifts are relative to the associated endianness.
The pixman formats are always relative to the host native endianness.
The qemu_pixman_get_format() method does not take into account the
VNC client endianness, and is thus returning a pixman format that is
only valid with the host endianness matches that of the VNC client.
This has been broken since pixman was introduced to the VNC server:
connecting from a LE client to a QEMU on a BE server, or the
reverse.
The bug was masked, however, because almost all VNC clients will
advertize support for the "tight" encoding and the QEMU VNC server
will prefer "tight" if advertized.
The tight_pack24 method is responsible for taking a set of pixels
which have already been converted into client endianness and then
repacking them into the TPIXEL format which the RFB spec defines
as
"TPIXEL is only 3 bytes long, where the first byte is the
red component, the second byte is the green component,
and the third byte is the blue component of the pixel
color value"
IOW, the TPIXEL format is fixed on the wire, regardless of what
the VNC client declare as its endianness.
Since the VNC pixel encoding code was failing to honour the endian
flag of the client, the tight_pack24 method was always operating
on data in native endianness. Its impl cancelled out the VNC pixel
encoding bug.
With the VNC pixel encoding code now fixed, the tight_pack24 method
needs to take into account that it is operating on data in client
endianness, not native endianness. It thus may need to invert the
pixel shifts.
Reviewed-by: Philippe Mathieu-Daudé <philmd@linaro.org> Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
(cherry picked from commit 70097442853c389a765c9f6502d861d182b092ae) Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>
ui/vnc.c: replace big endian flag with byte order value
It will make it easier to do certain comparisons in future if we
store G_BIG_ENDIAN/G_LITTLE_ENDIAN directly, instead of a boolean
flag, as we can then compare directly to the G_BYTE_ORDER constant.
Reviewed-by: BALATON Zoltan <balaton@eik.bme.hu> Reviewed-by: Philippe Mathieu-Daudé <philmd@linaro.org> Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
(cherry picked from commit 7ed96710e82c385c6cfc3d064eec7dde20f0f3fd) Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>
Weifeng Liu [Sun, 11 May 2025 07:33:15 +0000 (15:33 +0800)]
ui/sdl: Consider scaling in mouse event handling
When using sdl display backend, if the window is scaled, incorrect mouse
positions will be reported since scaling is not properly handled. Fix it
by transforming the positions from window coordinate to guest buffer
coordinate.
Signed-off-by: Weifeng Liu <weifeng.liu@intel.com>
Message-ID: <20250511073337.876650-6-weifeng.liu.z@gmail.com> Acked-by: Gerd Hoffmann <kraxel@redhat.com> Acked-by: Marc-André Lureau <marcandre.lureau@redhat.com>
(cherry picked from commit 30aa105640b0a2a541744b6584d57c9a4b86debd) Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>
Weifeng Liu [Sun, 11 May 2025 07:33:14 +0000 (15:33 +0800)]
ui/gtk: Update scales in fixed-scale mode when rendering GL area
When gl=on, scale_x and scale_y were set to 1 on startup that didn't
reflect the real situation of the scan-out in free scale mode, resulting
in incorrect cursor coordinates to be sent when moving the mouse
pointer. Simply updating the scales before rendering the image fixes
this issue.
Signed-off-by: Weifeng Liu <weifeng.liu.z@gmail.com>
Message-ID: <20250511073337.876650-5-weifeng.liu.z@gmail.com> Acked-by: Gerd Hoffmann <kraxel@redhat.com> Acked-by: Marc-André Lureau <marcandre.lureau@redhat.com>
(cherry picked from commit 8fb072472c38cb1778c5b0bebf535a8b13533857) Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>
Weifeng Liu [Sun, 11 May 2025 07:33:11 +0000 (15:33 +0800)]
ui/gtk: Document scale and coordinate handling
The existence of multiple scaling factors forces us to deal with various
coordinate systems and this would be confusing. It would be beneficial
to define the concepts clearly and use consistent representation for
variables in different coordinates.
Signed-off-by: Weifeng Liu <weifeng.liu.z@gmail.com>
Message-ID: <20250511073337.876650-2-weifeng.liu.z@gmail.com> Acked-by: Gerd Hoffmann <kraxel@redhat.com> Acked-by: Marc-André Lureau <marcandre.lureau@redhat.com>
(cherry picked from commit 9498e2f7e1a247557cfa0f830a86c398a23c6809) Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>
Jamin Lin [Thu, 22 May 2025 02:33:04 +0000 (10:33 +0800)]
hw/arm/aspeed_ast27x0: Fix RAM size detection failure on BE hosts
On big-endian hosts, the aspeed_ram_capacity_write() function previously passed
the address of a 64-bit "data" variable directly to address_space_write(),
assuming host and guest endianness matched.
However, the data is expected to be written in little-endian format to DRAM.
On big-endian hosts, this led to incorrect data being written into DRAM,
which caused the guest firmware to misdetect the DRAM size.
As a result, U-Boot fails to boot and hangs.
- Replaces the "address_space_write()" call with "address_space_stl_le()",
which performs an explicit 32-bit little-endian write.
- Updating the MemoryRegionOps to restrict access to exactly 4 bytes
using .valid.{min,max}_access_size = 4 and .impl.min_access_size = 4.
Jamin Lin [Thu, 15 May 2025 08:09:35 +0000 (16:09 +0800)]
hw/misc/aspeed_hace: Ensure HASH_IRQ is always set to prevent firmware hang
Currently, if the program encounters an unsupported algorithm, it does not set
the HASH_IRQ bit in the status register and send an interrupt to indicate
command completion. As a result, the FW gets stuck waiting for a completion
signal from the HACE module.
Additionally, in do_hash_operation, if an error occurs within the conditional
statement, the HASH_IRQ bit is not set in the status register. This causes the
firmware to continuously send HASH commands, as it is unaware that the HACE
model has completed processing the command.
To fix this, the HASH_IRQ bit in the status register must always be set to
ensure that the firmware receives an interrupt from the HACE module, preventing
it from getting stuck or repeatedly sending HASH commands.
Thomas Huth [Fri, 25 Apr 2025 12:07:10 +0000 (14:07 +0200)]
Drop support for Python 3.8
Python 3.8 went "end of life" in October 2024 and Fedora 42 dropped
this version already, so the "python" CI job is currently failing.
Thus it's time to drop support for this Python version in QEMU, too.
While we're at it, also look for "python3.13" in the configure script.
Message-ID: <20250425120710.879518-1-thuth@redhat.com> Reviewed-by: Philippe Mathieu-Daudé <philmd@linaro.org> Reviewed-by: Daniel P. Berrangé <berrange@redhat.com> Signed-off-by: Thomas Huth <thuth@redhat.com>
(cherry picked from commit d64db833d6e3cbe9ea5f36342480f920f3675cea) Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>
Helge Deller [Sat, 17 May 2025 11:27:48 +0000 (13:27 +0200)]
target/hppa: Fix FPE exceptions
Implement FP exception register #1 (lower 32-bits of 64-bit fr[0]).
A proper implementation is necessary to allow the Linux kernel in
system mode and the qemu linux-user to send proper si_code values
on SIGFPE signal.
Always set the T-bit on taken exception, and merge over- and underflow
in system mode to just set overflow bit to mimic the behaviour I tested
on a physical machine.
The test program below can be used to verify correct behaviour. Note
that behaviour on SIGFPE may vary on different platforms. The program
should always detect the correct signal, but it may or may not be able
to sucessfully continue afterwards.
Helge Deller [Sat, 17 May 2025 11:20:17 +0000 (13:20 +0200)]
linux-user/hppa: Send proper si_code on SIGFPE exception
Improve the linux-user emulation to send the correct si_code depending
on overflow (TARGET_FPE_FLTOVF), underflow (TARGET_FPE_FLTUND), ...
Note that the hardware stores the relevant flags in FP exception
register #1, which is actually the lower 32-bits of the 64-bit fr[0]
register in qemu.
Signed-off-by: Helge Deller <deller@gmx.de>
(cherry picked from commit b4b49cf39dba5f993ad925f204cb820aacfc8e45) Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>
Helge Deller [Sat, 17 May 2025 11:12:07 +0000 (13:12 +0200)]
target/hppa: Copy instruction code into fr1 on FPU assist fault
The hardware stores the instruction code in the lower bits of the FP
exception register #1 on FP assist traps.
This fixes the FP exception handler on Linux, as the Linux kernel uses
the value to decide on the correct signal which should be pushed into
userspace (see decode_fpu() in Linux kernel).
Signed-off-by: Helge Deller <deller@gmx.de>
(cherry picked from commit 923976dfe367b0bfed45ff660c369f3fe65604a7) Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>
Peter Xu [Tue, 13 May 2025 21:33:16 +0000 (17:33 -0400)]
migration: Allow caps to be set when preempt or multifd cap enabled
With commit 82137e6c8c ("migration: enforce multifd and postcopy preempt to
be set before incoming"), and if postcopy preempt / multifd is enabled, one
cannot setup any capability because these checks would always fail.
(qemu) migrate_set_capability xbzrle off
Error: Postcopy preempt must be set before incoming starts
To fix it, check existing cap and only raise an error if the specific cap
changed.
Fixes: 82137e6c8c ("migration: enforce multifd and postcopy preempt to be set before incoming") Reviewed-by: Dr. David Alan Gilbert <dave@treblig.org> Reviewed-by: Juraj Marcin <jmarcin@redhat.com> Signed-off-by: Peter Xu <peterx@redhat.com>
(cherry picked from commit 17bec9235bb0775cf8dec4103c167757ee8898f3) Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>
migration/multifd: Don't send device state packets with zerocopy flag
If zerocopy is enabled for multifd then QIO_CHANNEL_WRITE_FLAG_ZERO_COPY
flag is forced into all multifd channel write calls via p->write_flags
that was setup in multifd_nocomp_send_setup().
However, device state packets aren't compatible with zerocopy - the data
buffer isn't getting kept pinned until multifd channel flush.
Make sure to mask that QIO_CHANNEL_WRITE_FLAG_ZERO_COPY flag in a multifd
send thread if the data being sent is device state.
Zhao Liu [Tue, 13 May 2025 14:31:31 +0000 (22:31 +0800)]
qapi/misc-target: Fix the doc to distinguish query-sgx and query-sgx-capabilities
There're 2 QMP commands: query-sgx and query-sgx-capabilities, but
their outputs are very similar and the documentation lacks clear
differentiation.
From the codes, query-sgx is used to gather guest's SGX capabilities
(including SGX related CPUIDs and EPC sections' size, in SGXInfo), and
if guest doesn't have SGX, then QEMU will report the error message.
On the other hand, query-sgx-capabilities is used to gather host's SGX
capabilities (descripted by SGXInfo as well). And if host doesn't
support SGX, then QEMU will also report the error message.
Considering that SGXInfo is already documented and both these 2 commands
have enough error messages (for the exception case in their codes).
Therefore the QAPI documentation for these two commands only needs to
emphasize that one of them applies to the guest and the other to the
host.
Fix their documentation to reflect this difference.
The GT-64120 PCI controller requires special handling where:
1. Host bridge(bus 0 ,device 0) must never be byte-swapped
2. Other devices follow MByteSwap bit in GT_PCI0_CMD
The previous implementation incorrectly swapped all accesses, breaking
host bridge detection (lspci -d 11ab:4620).
Changes made:
1. Removed gt64120_update_pci_cfgdata_mapping() and moved data_mem initialization
to gt64120_realize() for cleaner setup
2. Implemented custom read/write handlers that:
- Preserve host bridge accesses (extract32(config_reg,11,13)==0)
- apply swapping only for non-bridge devices in big-endian mode
Fixes: 145e2198 ("hw/mips/gt64xxx_pci: Endian-swap using PCI_HOST_BRIDGE MemoryRegionOps")
Resolves: https://gitlab.com/qemu-project/qemu/-/issues/2826
Xiaoyao Li [Wed, 14 May 2025 03:16:52 +0000 (23:16 -0400)]
i386/hvf: Make CPUID_HT supported
Since Commit c6bd2dd63420 ("i386/cpu: Set up CPUID_HT in
x86_cpu_expand_features() instead of cpu_x86_cpuid()"), CPUID_HT will be
set in env->features[] in x86_cpu_expand_features() when vcpus >= 2.
Later in x86_cpu_filter_features() it will check against the HVF
supported bits. It will trigger the warning like
qemu-system-x86_64: warning: host doesn't support requested feature: CPUID.01H:EDX.ht [bit 28]
Add CPUID_HT to HVF supported CPUID bits to fix it.
Xiaoyao Li [Wed, 14 May 2025 03:16:51 +0000 (23:16 -0400)]
i386/tcg: Make CPUID_HT and CPUID_EXT3_CMP_LEG supported
Since commit c6bd2dd63420 ("i386/cpu: Set up CPUID_HT in
x86_cpu_expand_features() instead of cpu_x86_cpuid()") and
commit 99a637a86f55 ("i386/cpu: Set and track CPUID_EXT3_CMP_LEG in
env->features[FEAT_8000_0001_ECX]"), it gets warnings when booting the
VM with vcpus >= 2 and with tcg:
qemu-system-x86_64: warning: TCG doesn't support requested feature: CPUID.01H:EDX.ht [bit 28]
qemu-system-x86_64: warning: TCG doesn't support requested feature: CPUID.80000001H:ECX.cmp-legacy [bit 1]
This is because, after the two commits, CPUID_HT and CPUID_EXT3_CMP_LEG
are set in env->features[] when vcpus >=2 (in x86_cpu_expand_features())
later in x86_cpu_filter_features() it will check against the TCG supported
bits. However, current TCG doesn't mark the two bits as supported, hence
the warnings.
Fix it by adding the two bits to the supported bits of TCG since multiple
vcpus are supported by TCG.
Fixes: c6bd2dd63420 ("i386/cpu: Set up CPUID_HT in x86_cpu_expand_features() instead of cpu_x86_cpuid()") Fixes: 99a637a86f55 ("i386/cpu: Set and track CPUID_EXT3_CMP_LEG in env->features[FEAT_8000_0001_ECX]") Reported-by: Ewan Hai <ewanhai-oc@zhaoxin.com> Signed-off-by: Xiaoyao Li <xiaoyao.li@intel.com> Link: https://lore.kernel.org/r/20250514031652.838763-2-xiaoyao.li@intel.com Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
(cherry picked from commit 5979f50fa9fdbb3fb49e2b498f84faa7503c8ed1) Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>
[1] reports that commit 4db19d5b21 broke a KVM guest running kernel 6.6.
This happens because the kernel does not know 'senvcfg', making it
unable to boot because QEMU is reading/wriiting it without any checks.
After converting the CSRs to do "automated" get/put reg procedures in
the previous patch we can now scan for availability. Two functions are
created:
- kvm_riscv_read_csr_cfg_legacy() will check if the CSR exists by brute
forcing KVM_GET_ONE_REG in each one of them, interpreting an EINVAL
return as indication that the CSR isn't available. This will be use in
absence of KVM_GET_REG_LIST;
- kvm_riscv_read_csr_cfg() will use the existing result of get_reg_list
to check if the CSRs ids are present.
kvm_riscv_init_multiext_cfg() is now kvm_riscv_init_cfg() to reflect that
the function is also dealing with CSRs.
At this moment we're not checking if the host has support for any
specific CSR before doing get/put regs. This will cause problems if the
host KVM doesn't support it (see [1] as an example).
We'll use the same approach done with the CPU extensions: read all known
KVM CSRs during init() to check for availability, then read/write them
if they are present. This will be made by either using get-reglist or by
directly reading the CSRs.
For now we'll just convert the CSRs to use a kvm_csr_cfg[] array,
reusing the same KVMCPUConfig abstraction we use for extensions, and use
the array in (get|put)_csr_regs() instead of manually listing them. A
lot of boilerplate will be added but at least we'll automate the get/put
procedure for CSRs, i.e. adding a new CSR in the future will be a matter
of adding it in kvm_csr_regs[] and everything else will be taken care
of.
Despite all the code changes no behavioral change is made.
Signed-off-by: Daniel Henrique Barboza <dbarboza@ventanamicro.com> Reviewed-by: Andrew Jones <ajones@ventanamicro.com> Acked-by: Alistair Francis <alistair.francis@wdc.com>
Message-ID: <20250429124421.223883-6-dbarboza@ventanamicro.com> Signed-off-by: Alistair Francis <alistair.francis@wdc.com> Cc: qemu-stable@nongnu.org
(cherry picked from commit d3b6f1742c36e3a3c1e74cb60646ee98a4e39ea3) Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>
target/riscv/kvm: turn kvm_riscv_reg_id_ulong() into a macro
We need the reg_id_ulong() helper to be a macro to be able to create a
static array of KVMCPUConfig that will hold CSR information.
Despite the amount of changes all of them are tedious/trivial:
- replace instances of "kvm_riscv_reg_id_ulong" with
"KVM_RISCV_REG_ID_ULONG";
- RISCV_CORE_REG(), RISCV_CSR_REG(), RISCV_CONFIG_REG() and
RISCV_VECTOR_CSR_REG() only receives one 'name' arg. Remove unneeded
'env' variables when applicable.
Signed-off-by: Daniel Henrique Barboza <dbarboza@ventanamicro.com> Reviewed-by: Andrew Jones <ajones@ventanamicro.com> Reviewed-by: Alistair Francis <alistair.francis@wdc.com>
Message-ID: <20250429124421.223883-5-dbarboza@ventanamicro.com> Signed-off-by: Alistair Francis <alistair.francis@wdc.com> Cc: qemu-stable@nongnu.org
(cherry picked from commit 11766e17616a5a4181d4a63f88adf67ac52c553b) Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>
target/riscv/kvm: turn u32/u64 reg functions into macros
This change is motivated by a future change w.r.t CSRs management. We
want to handle them the same way as KVM extensions, i.e. a static array
with KVMCPUConfig objs that will be read/write during init and so on.
But to do that properly we must be able to declare a static array that
hold KVM regs.
C does not allow to init static arrays and use functions as
initializers, e.g. we can't do:
.kvm_reg_id = kvm_riscv_reg_id_ulong(...)
When instantiating the array. We can do that with macros though, so our
goal is turn kvm_riscv_reg_ulong() in a macro. It is cleaner to turn
every other reg_id_*() function in macros, and ulong will end up using
the macros for u32 and u64, so we'll start with them.
Signed-off-by: Daniel Henrique Barboza <dbarboza@ventanamicro.com> Reviewed-by: Andrew Jones <ajones@ventanamicro.com> Reviewed-by: Alistair Francis <alistair.francis@wdc.com>
Message-ID: <20250429124421.223883-4-dbarboza@ventanamicro.com> Signed-off-by: Alistair Francis <alistair.francis@wdc.com> Cc: qemu-stable@nongnu.org
(cherry picked from commit b6096103494506514d9bfa442f62fef36ffc8fba) Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>
target/riscv/kvm: fix leak in kvm_riscv_init_multiext_cfg()
'reglist' is being g-malloc'ed but never freed.
Reported-by: Andrew Jones <ajones@ventanamicro.com> Signed-off-by: Daniel Henrique Barboza <dbarboza@ventanamicro.com> Reviewed-by: Andrew Jones <ajones@ventanamicro.com> Reviewed-by: Alistair Francis <alistair.francis@wdc.com>
Message-ID: <20250429124421.223883-3-dbarboza@ventanamicro.com> Signed-off-by: Alistair Francis <alistair.francis@wdc.com> Cc: qemu-stable@nongnu.org
(cherry picked from commit 906af6de9462c5192547cca0beac2c134659a437) Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>
Remove an unused 'KVMScratchCPU' pointer argument in
kvm_riscv_check_sbi_dbcn_support().
Put kvm_riscv_reset_regs_csr() after kvm_riscv_put_regs_csr(). This will
make a future patch diff easier to read, when changes in
kvm_riscv_reset_regs_csr() and kvm_riscv_get_regs_csr() will be made.
Fixes: a6b53378f5 ("target/riscv/kvm: implement SBI debug console (DBCN) calls") Signed-off-by: Daniel Henrique Barboza <dbarboza@ventanamicro.com> Reviewed-by: Andrew Jones <ajones@ventanamicro.com> Reviewed-by: Alistair Francis <alistair.francis@wdc.com>
Message-ID: <20250429124421.223883-2-dbarboza@ventanamicro.com> Signed-off-by: Alistair Francis <alistair.francis@wdc.com> Cc: qemu-stable@nongnu.org
(cherry picked from commit 73f81da0a3628180409a0ae90ece19534bcdf09b) Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>
Anton Blanchard [Mon, 14 Apr 2025 21:30:06 +0000 (21:30 +0000)]
target/riscv: Fix vslidedown with rvv_ta_all_1s
vslidedown always zeroes elements past vl, where it should use the
tail policy.
Signed-off-by: Anton Blanchard <antonb@tenstorrent.com> Reviewed-by: Alistair Francis <alistair.francis@wdc.com>
Message-ID: <20250414213006.3509058-1-antonb@tenstorrent.com> Signed-off-by: Alistair Francis <alistair.francis@wdc.com> Cc: qemu-stable@nongnu.org
(cherry picked from commit 2669b696e243b64f8ea1a6468dcee255de99f08d) Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>
Max Chou [Tue, 8 Apr 2025 10:39:37 +0000 (18:39 +0800)]
target/riscv: rvv: Apply vext_check_input_eew to vector indexed load/store instructions
Handle the overlap of source registers with different EEWs.
Co-authored-by: Anton Blanchard <antonb@tenstorrent.com> Reviewed-by: Daniel Henrique Barboza <dbarboza@ventanamicro.com> Signed-off-by: Max Chou <max.chou@sifive.com>
Message-ID: <20250408103938.3623486-10-max.chou@sifive.com> Signed-off-by: Alistair Francis <alistair.francis@wdc.com> Cc: qemu-stable@nongnu.org
(cherry picked from commit db21c3eb05504c4cedaad4f7b19e588361b02385) Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>
Max Chou [Tue, 8 Apr 2025 10:39:36 +0000 (18:39 +0800)]
target/riscv: rvv: Apply vext_check_input_eew to vector narrow/widen instructions
Handle the overlap of source registers with different EEWs.
The vd of vector widening mul-add instructions is one of the input
operands.
Co-authored-by: Anton Blanchard <antonb@tenstorrent.com> Reviewed-by: Daniel Henrique Barboza <dbarboza@ventanamicro.com> Signed-off-by: Max Chou <max.chou@sifive.com>
Message-ID: <20250408103938.3623486-9-max.chou@sifive.com> Signed-off-by: Alistair Francis <alistair.francis@wdc.com> Cc: qemu-stable@nongnu.org
(cherry picked from commit 1f090a229f85e662394267680408bd31fd0a99c9) Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>
Max Chou [Tue, 8 Apr 2025 10:39:35 +0000 (18:39 +0800)]
target/riscv: rvv: Apply vext_check_input_eew to vector integer extension instructions(OPMVV)
Handle the overlap of source registers with different EEWs.
Co-authored-by: Anton Blanchard <antonb@tenstorrent.com> Reviewed-by: Daniel Henrique Barboza <dbarboza@ventanamicro.com> Signed-off-by: Max Chou <max.chou@sifive.com>
Message-ID: <20250408103938.3623486-8-max.chou@sifive.com> Signed-off-by: Alistair Francis <alistair.francis@wdc.com> Cc: qemu-stable@nongnu.org
(cherry picked from commit 411eefd56a3921ddbfdbadca596e1a8593ce834c) Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>
Max Chou [Tue, 8 Apr 2025 10:39:34 +0000 (18:39 +0800)]
target/riscv: rvv: Apply vext_check_input_eew to vector slide instructions(OPIVI/OPIVX)
Handle the overlap of source registers with different EEWs.
Co-authored-by: Anton Blanchard <antonb@tenstorrent.com> Reviewed-by: Daniel Henrique Barboza <dbarboza@ventanamicro.com> Signed-off-by: Max Chou <max.chou@sifive.com>
Message-ID: <20250408103938.3623486-7-max.chou@sifive.com> Signed-off-by: Alistair Francis <alistair.francis@wdc.com> Cc: qemu-stable@nongnu.org
(cherry picked from commit b5480a693e3e657108746721ffe434b3bb6e7a72) Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>
Max Chou [Tue, 8 Apr 2025 10:39:33 +0000 (18:39 +0800)]
target/riscv: rvv: Apply vext_check_input_eew to OPIVV/OPFVV(vext_check_sss) instructions
Handle the overlap of source registers with different EEWs.
Co-authored-by: Anton Blanchard <antonb@tenstorrent.com> Reviewed-by: Daniel Henrique Barboza <dbarboza@ventanamicro.com> Signed-off-by: Max Chou <max.chou@sifive.com>
Message-ID: <20250408103938.3623486-6-max.chou@sifive.com> Signed-off-by: Alistair Francis <alistair.francis@wdc.com> Cc: qemu-stable@nongnu.org
(cherry picked from commit fda68acb7761af40df78db18e44ca1ff20195fe0) Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>
Max Chou [Tue, 8 Apr 2025 10:39:32 +0000 (18:39 +0800)]
target/riscv: rvv: Apply vext_check_input_eew to OPIVI/OPIVX/OPFVF(vext_check_ss) instructions
Handle the overlap of source registers with different EEWs.
Co-authored-by: Anton Blanchard <antonb@tenstorrent.com> Reviewed-by: Daniel Henrique Barboza <dbarboza@ventanamicro.com> Signed-off-by: Max Chou <max.chou@sifive.com>
Message-ID: <20250408103938.3623486-5-max.chou@sifive.com> Signed-off-by: Alistair Francis <alistair.francis@wdc.com> Cc: qemu-stable@nongnu.org
(cherry picked from commit fbeaf35838768086b435833cb4dc5182c73ec2bc) Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>
Max Chou [Tue, 8 Apr 2025 10:39:31 +0000 (18:39 +0800)]
target/riscv: rvv: Apply vext_check_input_eew to vrgather instructions to check mismatched input EEWs encoding constraint
According to the v spec, a vector register cannot be used to provide source
operands with more than one EEW for a single instruction.
The vs1 EEW of vrgatherei16.vv is 16.
Co-authored-by: Anton Blanchard <antonb@tenstorrent.com> Reviewed-by: Daniel Henrique Barboza <dbarboza@ventanamicro.com> Signed-off-by: Max Chou <max.chou@sifive.com>
Message-ID: <20250408103938.3623486-4-max.chou@sifive.com> Signed-off-by: Alistair Francis <alistair.francis@wdc.com> Cc: qemu-stable@nongnu.org
(cherry picked from commit 629c2a8dd7506e1cb9b6b7127604641632ac453f) Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>
Anton Blanchard [Tue, 8 Apr 2025 10:39:30 +0000 (18:39 +0800)]
target/riscv: rvv: Add CHECK arg to GEN_OPFVF_WIDEN_TRANS
Signed-off-by: Anton Blanchard <antonb@tenstorrent.com> Reviewed-by: Daniel Henrique Barboza <dbarboza@ventanamicro.com> Reviewed-by: Max Chou <max.chou@sifive.com> Signed-off-by: Max Chou <max.chou@sifive.com>
Message-ID: <20250408103938.3623486-3-max.chou@sifive.com> Signed-off-by: Alistair Francis <alistair.francis@wdc.com> Cc: qemu-stable@nongnu.org
(cherry picked from commit b0450a101d6c88789d0e8df2bcbef61bc7cd159a) Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>
Add the relevant ISA paragraphs explaining why source (and destination)
registers cannot overlap the mask register.
Signed-off-by: Anton Blanchard <antonb@tenstorrent.com> Reviewed-by: Daniel Henrique Barboza <dbarboza@ventanamicro.com> Reviewed-by: Max Chou <max.chou@sifive.com> Signed-off-by: Max Chou <max.chou@sifive.com>
Message-ID: <20250408103938.3623486-2-max.chou@sifive.com> Signed-off-by: Alistair Francis <alistair.francis@wdc.com> Cc: qemu-stable@nongnu.org
(cherry picked from commit 3e8d1e4a628bb234c0b5d1ccd510900047181dbd) Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>
common-user/host/riscv: use tail pseudoinstruction for calling tail
The j pseudoinstruction maps to a JAL instruction, which can only handle
a jump to somewhere with a signed 20-bit destination. In case of static
linking and LTO'ing this easily leads to "relocation truncated to fit"
error.
Switch to use tail pseudoinstruction, which is the standard way to
tail-call a function in medium code model (emits AUIPC+JALR).
Signed-off-by: Icenowy Zheng <uwu@icenowy.me> Reviewed-by: Richard Henderson <richard.henderson@linaro.org>
Message-ID: <20250417072206.364008-1-uwu@icenowy.me> Signed-off-by: Alistair Francis <alistair.francis@wdc.com> Cc: qemu-stable@nongnu.org
(cherry picked from commit 22b448ccc6611a59d4aa54419f4d88c1f343cb35) Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>
Ziqiao Kong [Tue, 15 Apr 2025 08:02:54 +0000 (16:02 +0800)]
target/riscv: fix endless translation loop on big endian systems
On big endian systems, pte and updated_pte hold big endian host data
while pte_pa points to little endian target data. This means the branch
at cpu_helper.c:1669 will be always satisfied and restart translation,
causing an endless translation loop.
The correctness of this patch can be deduced by:
old_pte will hold value either from cpu_to_le32/64(pte) or
cpu_to_le32/64(updated_pte), both of wich is litte endian. After that,
an in-place conversion by le32/64_to_cpu(old_pte) ensures that old_pte
now is in native endian, same with pte. Therefore, the endianness of the
both side of if (old_pte != pte) is correct.
Signed-off-by: Ziqiao Kong <ziqiaokong@gmail.com> Reviewed-by: Alistair Francis <alistair.francis@wdc.com> Reviewed-by: Richard Henderson <richard.henderson@linaro.org>
Message-ID: <20250415080254.3667878-2-ziqiaokong@gmail.com> Signed-off-by: Alistair Francis <alistair.francis@wdc.com> Cc: qemu-stable@nongnu.org
(cherry picked from commit ad63158bdb33dab5704ea1cf740d2ea0387175df) Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>
Paolo Bonzini [Thu, 10 Apr 2025 16:17:22 +0000 (18:17 +0200)]
hw/riscv: Fix type conflict of GLib function pointers
qtest_set_command_cb passed to g_once should match GThreadFunc,
which it does not. But using g_once is actually unnecessary,
because the function is called by riscv_harts_realize() under
the Big QEMU Lock.
Reported-by: Kohei Tokunaga <ktokunaga.mail@gmail.com> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com> Reviewed-by: Alistair Francis <alistair.francis@wdc.com> Reviewed-by: Kohei Tokunaga <ktokunaga.mail@gmail.com> Reviewed-by: Philippe Mathieu-Daudé <philmd@linaro.org>
Message-ID: <20250410161722.595634-1-pbonzini@redhat.com> Signed-off-by: Alistair Francis <alistair.francis@wdc.com> Cc: qemu-stable@nongnu.org
(cherry picked from commit 56cde18d048e1e1f889e31f7553e1f39f03eeec5) Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>
Loïc Lefort [Thu, 13 Mar 2025 19:30:09 +0000 (20:30 +0100)]
target/riscv: pmp: fix checks on writes to pmpcfg in Smepmp MML mode
With Machine Mode Lockdown (mseccfg.MML) set and RLB not set, checks on pmpcfg
writes would match the wrong cases of Smepmp truth table.
The existing code allows writes for the following cases:
- L=1, X=0: cases 8, 10, 12, 14
- L=0, RWX!=WX: cases 0-2, 4-6
This leaves cases 3, 7, 9, 11, 13, 15 for which writes are ignored.
From the Smepmp specification: "Adding a rule with executable privileges that
either is M-mode-only or a locked Shared-Region is not possible (...)" This
description matches cases 9-11, 13 of the truth table.
This commit implements an explicit check for these cases by using
pmp_get_epmp_operation to convert between PMP configuration and Smepmp truth
table cases.
Signed-off-by: Loïc Lefort <loic@rivosinc.com> Reviewed-by: Daniel Henrique Barboza <dbarboza@ventanamicro.com> Reviewed-by: LIU Zhiwei <zhiwei_liu@linux.alibaba.com>
Message-ID: <20250313193011.720075-4-loic@rivosinc.com> Signed-off-by: Alistair Francis <alistair.francis@wdc.com> Cc: qemu-stable@nongnu.org
(cherry picked from commit 19cf1a7d9e59b71bf8d6571d4747e5c82667c3d1) Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>
Loïc Lefort [Thu, 13 Mar 2025 19:30:07 +0000 (20:30 +0100)]
target/riscv: pmp: don't allow RLB to bypass rule privileges
When Smepmp is supported, mseccfg.RLB allows bypassing locks when writing CSRs
but should not affect interpretation of actual PMP rules.
This is not the case with the current implementation where pmp_hart_has_privs
calls pmp_is_locked which implements mseccfg.RLB bypass.
This commit implements the correct behavior by removing mseccfg.RLB bypass from
pmp_is_locked.
RLB bypass when writing CSRs is implemented by adding a new pmp_is_readonly
function that calls pmp_is_locked and check mseccfg.RLB. pmp_write_cfg and
pmpaddr_csr_write are changed to use this new function.
Signed-off-by: Loïc Lefort <loic@rivosinc.com> Reviewed-by: Alistair Francis <alistair.francis@wdc.com> Reviewed-by: Daniel Henrique Barboza <dbarboza@ventanamicro.com> Reviewed-by: LIU Zhiwei <zhiwei_liu@linux.alibaba.com>
Message-ID: <20250313193011.720075-2-loic@rivosinc.com> Signed-off-by: Alistair Francis <alistair.francis@wdc.com> Cc: qemu-stable@nongnu.org
(cherry picked from commit 4541d205f03cf1529439f68d2ec5056685189399) Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>
virtio-net expects set_features() will be called when the feature set
used by the guest changes to update the number of virtqueues but it is
not called during reset, which will clear all features, leaving the
queues added for VIRTIO_NET_F_MQ or VIRTIO_NET_F_RSS. Not only these
extra queues are visible to the guest, they will cause segmentation
fault during migration.
Call set_features() during reset to remove those queues for virtio-net
as we call set_status(). It will also prevent similar bugs for
virtio-net and other devices in the future.
Fixes: f9d6dbf0bf6e ("virtio-net: remove virtio queues if the guest doesn't support multiqueue") Buglink: https://issues.redhat.com/browse/RHEL-73842 Cc: qemu-stable@nongnu.org Signed-off-by: Akihiko Odaki <akihiko.odaki@daynix.com>
Message-Id: <20250421-reset-v2-1-e4c1ead88ea1@daynix.com> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
(cherry picked from commit 0caed25cd171c611781589b5402161d27d57229c) Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>
Fabiano Rosas [Fri, 9 May 2025 17:49:38 +0000 (14:49 -0300)]
s390x: Fix leak in machine_set_loadparm
ASAN spotted a leaking string in machine_set_loadparm():
Direct leak of 9 byte(s) in 1 object(s) allocated from:
#0 0x560ffb5bb379 in malloc ../projects/compiler-rt/lib/asan/asan_malloc_linux.cpp:69:3
#1 0x7f1aca926518 in g_malloc ../glib/gmem.c:106
#2 0x7f1aca94113e in g_strdup ../glib/gstrfuncs.c:364
#3 0x560ffc8afbf9 in qobject_input_type_str ../qapi/qobject-input-visitor.c:542:12
#4 0x560ffc8a80ff in visit_type_str ../qapi/qapi-visit-core.c:349:10
#5 0x560ffbe6053a in machine_set_loadparm ../hw/s390x/s390-virtio-ccw.c:802:10
#6 0x560ffc0c5e52 in object_property_set ../qom/object.c:1450:5
#7 0x560ffc0d4175 in object_property_set_qobject ../qom/qom-qobject.c:28:10
#8 0x560ffc0c6004 in object_property_set_str ../qom/object.c:1458:15
#9 0x560ffbe2ae60 in update_machine_ipl_properties ../hw/s390x/ipl.c:569:9
#10 0x560ffbe2aa65 in s390_ipl_update_diag308 ../hw/s390x/ipl.c:594:5
#11 0x560ffbdee132 in handle_diag_308 ../target/s390x/diag.c:147:9
#12 0x560ffbebb956 in helper_diag ../target/s390x/tcg/misc_helper.c:137:9
#13 0x7f1a3c51c730 (/memfd:tcg-jit (deleted)+0x39730)
Cc: qemu-stable@nongnu.org Signed-off-by: Fabiano Rosas <farosas@suse.de>
Message-ID: <20250509174938.25935-1-farosas@suse.de> Fixes: 1fd396e3228 ("s390x: Register TYPE_S390_CCW_MACHINE properties as class properties") Reviewed-by: Thomas Huth <thuth@redhat.com> Reviewed-by: Philippe Mathieu-Daudé <philmd@linaro.org> Signed-off-by: Thomas Huth <thuth@redhat.com>
(cherry picked from commit bdf12f2a56bf3f13c52eb51f0a994bbfe40706b2) Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>
9pfs: fix FD leak and reduce latency of v9fs_reclaim_fd()
This patch fixes two different bugs in v9fs_reclaim_fd():
1. Reduce latency:
This function calls v9fs_co_close() and v9fs_co_closedir() in a loop. Each
one of the calls adds two thread hops (between main thread and a fs driver
background thread). Each thread hop adds latency, which sums up in
function's loop to a significant duration.
Reduce overall latency by open coding what v9fs_co_close() and
v9fs_co_closedir() do, executing those and the loop itself altogether in
only one background thread block, hence reducing the total amount of
thread hops to only two.
2. Fix file descriptor leak:
The existing code called v9fs_co_close() and v9fs_co_closedir() to close
file descriptors. Both functions check right at the beginning if the 9p
request was cancelled:
if (v9fs_request_cancelled(pdu)) {
return -EINTR;
}
So if client sent a 'Tflush' message, v9fs_co_close() / v9fs_co_closedir()
returned without having closed the file descriptor and v9fs_reclaim_fd()
subsequently freed the FID without its file descriptor being closed, hence
leaking those file descriptors.
This 2nd bug is fixed by this patch as well by open coding v9fs_co_close()
and v9fs_co_closedir() inside of v9fs_reclaim_fd() and not performing the
v9fs_request_cancelled(pdu) check there.
Fixes: 7a46274529c ('hw/9pfs: Add file descriptor reclaim support') Fixes: bccacf6c792 ('hw/9pfs: Implement TFLUSH operation') Signed-off-by: Christian Schoenebeck <qemu_oss@crudebyte.com> Reviewed-by: Greg Kurz <groug@kaod.org>
Message-Id: <5747469d3f039c53147e850b456943a1d4b5485c.1741339452.git.qemu_oss@crudebyte.com>
(cherry picked from commit 89f7b4da7662ecc6840ffb0846045f03f9714bc6) Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>
Even though this function is serialized to be always called from main
thread, v9fs_reclaim_fd() is dispatching the coroutine to a worker thread
in between via its v9fs_co_*() calls, hence leading to the situation where
v9fs_reclaim_fd() is effectively executed multiple times simultaniously,
which renders its LRU algorithm useless and causes high latency.
Fix this by adding a simple boolean variable to ensure this function is
only called once at a time. No synchronization needed for this boolean
variable as this function is only entered and returned on main thread.
Fixes: 7a46274529c ('hw/9pfs: Add file descriptor reclaim support') Signed-off-by: Christian Schoenebeck <qemu_oss@crudebyte.com> Reviewed-by: Greg Kurz <groug@kaod.org>
Message-Id: <5c622067efd66dd4ee5eca740dcf263f41db20b2.1741339452.git.qemu_oss@crudebyte.com>
(cherry picked from commit 61da38db70affd925226ce1e8a61d761c20d045b) Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>
hw/i2c/imx: Always set interrupt status bit if interrupt condition occurs
According to the i.MX 8M Plus reference manual, the status flag
I2C_I2SR[IIF] continues to be set when an interrupt condition
occurs even when I2C interrupts are disabled (I2C_I2CR[IIEN] is
clear). However, the device model only sets the flag when I2C
interrupts are enabled which causes U-Boot to loop forever. Fix
the device model by always setting the flag and let I2C_I2CR[IIEN]
guard I2C interrupts only.
Also remove the comment in the code since it merely stated the
obvious and would be outdated now.
Cc: qemu-stable@nongnu.org Fixes: 20d0f9cf6a41 ("i.MX: Add I2C controller emulator") Signed-off-by: Bernhard Beschow <shentey@gmail.com> Acked-by: Corey Minyard <cminyard@mvista.com>
Message-ID: <20250507124040.425773-1-shentey@gmail.com> Signed-off-by: Philippe Mathieu-Daudé <philmd@linaro.org>
(cherry picked from commit 54e54e594bc8273d210f7ff4448c165a989cbbe8) Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>
Today, we don't track write-abiliy in the cache, if a user
requests a readable mapping followed by a writeable mapping
on the same page, the second lookup will incorrectly hit
the readable entry.
Split mapcache_grants by ro and rw access. Grants will now
have separate ways in the cache depending on writeability.
Reviewed-by: Philippe Mathieu-Daudé <philmd@linaro.org> Reviewed-by: Stefano Stabellini <sstabellini@kernel.org> Signed-off-by: Edgar E. Iglesias <edgar.iglesias@amd.com>
(cherry picked from commit 88fb705600a3b612c571efc9f1a6aed923a18dcc) Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>
If we have request without lock and hit unlocked or invalid
entry during the search, we remap it immediately,
even if we have matching entry in next entries in bucket.
This leads to duplication of mappings of the same size,
and to possibility of selecting the wrong element
during invalidation and underflow it's entry->lock counter
Signed-off-by: Aleksandr Partanen <alex.pentagrid@gmail.com> Reviewed-by: Stefano Stabellini <sstabellini@kernel.org> Reviewed-by: Edgar E. Iglesias <edgar.iglesias@amd.com> Signed-off-by: Edgar E. Iglesias <edgar.iglesias@amd.com>
(cherry picked from commit a4b20f737cda06bb8706a83e27f7fa89863ae689) Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>
Paolo Bonzini [Mon, 15 Jul 2024 08:35:06 +0000 (10:35 +0200)]
target/i386: do not block singlestep for STI
STI will trigger a singlestep exception even if it has inhibit-IRQ
behavior. Do not suppress single-step for all IRQ-inhibiting
instructions, instead special case MOV SS and POP SS.
Cc: qemu-stable@nongnu.org Fixes: f0f0136abba ("target/i386: no single-step exception after MOV or POP SS", 2024-05-25) Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
(cherry picked from commit 1e94ddc6854431064c94a7d8f2f2886def285829) Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>
Paolo Bonzini [Thu, 8 May 2025 09:32:11 +0000 (11:32 +0200)]
target/i386: do not trigger IRQ shadow for LSS
Because LSS need not trigger an IRQ shadow, gen_movl_seg can't just use
the destination register to decide whether to inhibit IRQs. Add an
argument.
Cc: qemu-stable@nongnu.org Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
(cherry picked from commit e54ef98c8a80d16158bab4341d9a898701270528)
(back-ported to 10.0) Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>
hw/gpio/imx_gpio: Fix interpretation of GDIR polarity
According to the i.MX 8M Plus reference manual, a GPIO pin is
configured as an output when the corresponding bit in the GDIR
register is set. The function imx_gpio_set_int_line() is intended to
be a no-op if the pin is configured as an output, returning early in
such cases. However, it inverts the condition. Fix this by
returning early when the bit is set.
cc: qemu-stable@nongnu.org Fixes: f44272809779 ("i.MX: Add GPIO device") Signed-off-by: Bernhard Beschow <shentey@gmail.com>
Message-id: 20250501183445.2389-4-shentey@gmail.com Reviewed-by: Peter Maydell <peter.maydell@linaro.org> Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
(cherry picked from commit eba837a31b9579e30cc6d7ecb4b5c2662a6ffaba) Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>
Peter Maydell [Thu, 1 May 2025 09:31:26 +0000 (10:31 +0100)]
docs: Don't define duplicate label in qemu-block-drivers.rst.inc
Sphinx requires that labels within documents are unique across the
whole manual. This is because the "create a hyperlink" directive
specifies only the name of the label, not a filename+label. Some
Sphinx versions will warn about duplicate labels, but even if there
is no warning there is still an ambiguity and no guarantee that the
hyperlink will be created to the right target.
For QEMU this is awkward, because we have various .rst.inc fragments
which we include into multiple .rst files. If you define a label in
the .rst.inc file then it will be a duplicate label. We have mostly
worked around this by not putting labels into those .rst.inc files,
or by adding "insert a label" functionality into the hxtool extension
(see commit 1eeb432a953b0 "doc/sphinx/hxtool.py: add optional label
argument to SRST directive").
Unfortunately in commit 7f6314427e78 ("docs/devel: add a codebase
section") we accidentally added a duplicate label, because not all
Sphinx versions warn about the mistake.
In this case the link was only from the developer docs codebase
summary, so as the simplest fix for the stable branch, we drop
the link entirely.
Cc: qemu-stable@nongnu.org Fixes: 1eeb432a953b0 "doc/sphinx/hxtool.py: add optional label argument to SRST directive" Reported-by: Dario Faggioli <dfaggioli@suse.com> Signed-off-by: Peter Maydell <peter.maydell@linaro.org> Acked-by: Eric Blake <eblake@redhat.com> Reviewed-by: Pierrick Bouvier <pierrick.bouvier@linaro.org>
Message-id: 20250501093126.716667-1-peter.maydell@linaro.org
(cherry picked from commit 82707dd4f07613eed8d639956a43bddffca5cd5c) Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>
Both calls are in arm_tr_tb_stop(), one for the
DISAS_NEXT/DISAS_TOO_MANY handling, and one for the dc->condjump
condition-failed codepath. The DISAS_NEXT handling doesn't have this
problem because arm_post_translate_insn() does the handling of "emit
the label for the condition-failed conditional execution" and so
arm_tr_tb_stop() doesn't have dc->condjump set. But for
DISAS_TOO_MANY we don't do that.
Fix the bug by making arm_post_translate_insn() handle the
DISAS_TOO_MANY case. This only affects the SB and ISB insns when
used in Thumb mode inside an IT block: only these insns specifically
set is_jmp to TOO_MANY, and their A32 encodings are unconditional.
For the major TOO_MANY case (breaking the TB because it would cross a
page boundary) we do that check and set is_jmp to TOO_MANY only after
the call to arm_post_translate_insn(); so arm_post_translate_insn()
sees is_jmp == DISAS_NEXT, and we emit the correct code for that
situation.
With this fix we generate the somewhat more sensible set of TCG ops:
brcond_i32 ZF,$0x0,ne,$L1
set_label $L1
add_i32 pc,pc,$0x4
goto_tb $0x1
exit_tb $0x7c5434001b81
(NB: the TCG optimizer doesn't optimize out the jump-to-next, but
we can't really avoid emitting it because we don't know at the
point we're emitting the handling for the condexec check whether
this insn is going to happen to be a nop for us or not.)
Cc: qemu-stable@nongnu.org Fixes: https://gitlab.com/qemu-project/qemu/-/issues/2942 Signed-off-by: Peter Maydell <peter.maydell@linaro.org> Reviewed-by: Richard Henderson <richard.henderson@linaro.org>
Message-id: 20250501125544.727038-1-peter.maydell@linaro.org
(cherry picked from commit 8ed7c0b6488a7f20318d6ba414f1cbcd0ed92afe) Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>
Tim Lee [Mon, 28 Apr 2025 02:29:34 +0000 (10:29 +0800)]
hw/arm/npcm8xx_boards: Correct valid_cpu_types setting of NPCM8XX SoC
NPCM8XX SoC is the successor of the NPCM7XX. It features quad-core
Cortex-A35 (Armv8, 64-bit) CPUs and some additional peripherals.
Correct the `valid_cpu_types` setting to match the NPCM8XX SoC.
Cc: qemu-stable@nongnu.org Fixes: 7e70eb3cad7c83 ("hw/arm: Add NPCM845 Evaluation board") Signed-off-by: Tim Lee <timlee660101@gmail.com>
Message-id: 20250428022934.3081139-1-timlee660101@gmail.com Reviewed-by: Peter Maydell <peter.maydell@linaro.org> Reviewed-by: Tyrone Ting <kfting@nuvoton.com> Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
(cherry picked from commit 97cdd1b0a7a010702a1d118b74c3af3bb2edb35c) Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>
macOS SDK may have the symbol of strchrnul(), but it is actually
available only on macOS 15.4 or later and that fact is codified in
string.h. Include the header file using osdep_prefix to check if the
function is available on the deployment target.
Cc: qemu-stable@nongnu.org Signed-off-by: Akihiko Odaki <akihiko.odaki@daynix.com> Reviewed-by: Philippe Mathieu-Daudé <philmd@linaro.org> Tested-by: Philippe Mathieu-Daudé <philmd@linaro.org>
Message-ID: <20250424-buildsys-v1-4-97655e3b25d7@daynix.com> Signed-off-by: Philippe Mathieu-Daudé <philmd@linaro.org>
(cherry picked from commit a5b30be534538dc6e44a68ce9734e45dd08f52ec) Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>
gnu_source_prefix defines _GNU_SOURCE for compiler object functions.
The definition is universally available in the code base.
docs/devel/style.rst also says that the "qemu/osdep.h" header is
always included, so files included in the file is also universally
available in the code base.
Rename gnu_source_prefix to osdep_prefix, and add #include directives
that are referred by the users of gnu_source_prefix and contained in
qemu/osdep.h to safely de-duplicate #include directives.
Cc: qemu-stable@nongnu.org Signed-off-by: Akihiko Odaki <akihiko.odaki@daynix.com> Reviewed-by: Philippe Mathieu-Daudé <philmd@linaro.org> Tested-by: Philippe Mathieu-Daudé <philmd@linaro.org>
Message-ID: <20250424-buildsys-v1-3-97655e3b25d7@daynix.com> Signed-off-by: Philippe Mathieu-Daudé <philmd@linaro.org>
(cherry picked from commit 797150d69d2edba8b1bd4a7d8c7ba2df1219c503) Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>
The use of gnu_source_prefix in the detection of getcpu() was
ineffective because the header file that declares getcpu() when
_GNU_SOURCE is defined was not included. Pass sched.h to
has_header_symbol() so that the existence of the declaration will be
properly checked.
Cc: qemu-stable@nongnu.org Signed-off-by: Akihiko Odaki <akihiko.odaki@daynix.com> Reviewed-by: Philippe Mathieu-Daudé <philmd@linaro.org> Tested-by: Philippe Mathieu-Daudé <philmd@linaro.org>
Message-ID: <20250424-buildsys-v1-1-97655e3b25d7@daynix.com> Signed-off-by: Philippe Mathieu-Daudé <philmd@linaro.org>
(cherry picked from commit 563cd698dffb977eea0ccfef3b95f6f9786766f3) Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>
Peter Maydell [Mon, 17 Mar 2025 14:28:11 +0000 (14:28 +0000)]
hw/core/cpu: gdb_arch_name string should not be freed
The documentation for the CPUClass::gdb_arch_name method claims that
the returned string should be freed with g_free(). This is not
correct: in commit a650683871ba728 we changed this method to
instead return a simple constant string, but forgot to update
the documentation.
Make the documentation match the new semantics.
Fixes: a650683871ba728 ("hw/core/cpu: Return static value with gdb_arch_name()") Signed-off-by: Peter Maydell <peter.maydell@linaro.org> Reviewed-by: Alex Bennée <alex.bennee@linaro.org> Reviewed-by: Philippe Mathieu-Daudé <philmd@linaro.org>
Message-ID: <20250317142819.900029-2-peter.maydell@linaro.org> Signed-off-by: Philippe Mathieu-Daudé <philmd@linaro.org>
(cherry picked from commit 56a9f0d4c4a483ce217e5290db69cb1788586787) Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>
hw/core: Get default_cpu_type calling machine_class_default_cpu_type()
Since commit 62b4a227a33 the default cpu type can come from the
valid_cpu_types[] array. Call the machine_class_default_cpu_type()
instead of accessing MachineClass::default_cpu_type field.
Cc: qemu-stable@nongnu.org Fixes: 62b4a227a33 ("hw/core: Add machine_class_default_cpu_type()") Signed-off-by: Philippe Mathieu-Daudé <philmd@linaro.org> Reviewed-by: Richard Henderson <richard.henderson@linaro.org> Reviewed-by: Pierrick Bouvier <pierrick.bouvier@linaro.org> Reviewed-by: Zhao Liu <zhao1.liu@intel.com>
Message-Id: <20250422084114.39499-1-philmd@linaro.org>
(cherry picked from commit d5f241834be1b323ea697a469ff0f1335a1823fe) Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>
The comment about not being able to define a field with
zero bits is out of date since 94597b6146f3
("decodetree: Allow !function with no input bits").
This fixes the missing load of imm in the disassembler.
Cc: qemu-stable@nongnu.org Fixes: 9d8caa67a24 ("target/avr: Add support for disassembling via option '-d in_asm'") Reviewed-by: Pierrick Bouvier <pierrick.bouvier@linaro.org> Signed-off-by: Richard Henderson <richard.henderson@linaro.org>
(cherry picked from commit 6b661b7ed7cd02c54a78426d5eb7dd8543b030ed) Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>
Paolo Bonzini [Thu, 3 Apr 2025 19:39:54 +0000 (21:39 +0200)]
target/i386/hvf: fix lflags_to_rflags
Clear the flags before adding in the ones computed from lflags.
Cc: Wei Liu <liuwe@linux.microsoft.com> Cc: qemu-stable@nongnu.org Reviewed-by: Philippe Mathieu-Daudé <philmd@linaro.org> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
(cherry picked from commit 94a159f3dc737d00749cc930adaec112abe07b3c) Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>
target/i386: Reset parked vCPUs together with the online ones
Commit 3f2a05b31ee9 ("target/i386: Reset TSCs of parked vCPUs too on VM
reset") introduced a way to reset TSCs of parked vCPUs during VM reset to
prevent them getting desynchronized with the online vCPUs and therefore
causing the KVM PV clock to lose PVCLOCK_TSC_STABLE_BIT.
The way this was done was by registering a parked vCPU-specific QEMU reset
callback via qemu_register_reset().
However, it turns out that on particularly device-rich VMs QEMU reset
callbacks can take a long time to execute (which isn't surprising,
considering that they involve resetting all of VM devices).
In particular, their total runtime can exceed the 1-second TSC
synchronization window introduced in KVM commit 5d3cb0f6a8e3 ("KVM:
Improve TSC offset matching").
Since the TSCs of online vCPUs are only reset from "synchronize_post_reset"
AccelOps handler (which runs after all qemu_register_reset() handlers) this
essentially makes that fix ineffective on these VMs.
The easiest way to guarantee that these parked vCPUs are reset at the same
time as the online ones (regardless how long it takes for VM devices to
reset) is to piggyback on post-reset vCPU synchronization handler for one
of online vCPUs - as there is no generic post-reset AccelOps handler that
isn't per-vCPU.
The first online vCPU was selected for that since it is easily available
under "first_cpu" define.
This does not create an ordering issue since the order of vCPU TSC resets
does not matter.
Ewan Hai [Mon, 14 Apr 2025 07:53:42 +0000 (03:53 -0400)]
target/i386: Fix model number of Zhaoxin YongFeng vCPU template
The model number was mistakenly set to 0x0b (11) in commit ff04bc1ac4.
The correct value is 0x5b. This mistake occurred because the extended
model bits in cpuid[eax=0x1].eax were overlooked, and only the base
model was used.
Using the wrong model number can affect guest behavior. One known issue
is that vPMU (which relies on the model number) may fail to operate
correctly.
This patch corrects the model field by introducing a new vCPU version.
The goal was to remove the need to patch the (const) input buffer
with a recomputed UDP checksum by copying headers to a RW region and
inject the checksum there. The patch computed the checksum only from the
header fields (missing the rest of the payload) producing an invalid one
and making guests fail to acquire a DHCP lease.
Resolves: https://gitlab.com/qemu-project/qemu/-/issues/2727 Cc: qemu-stable@nongnu.org Signed-off-by: Antoine Damhet <adamhet@scaleway.com> Acked-by: Michael S. Tsirkin <mst@redhat.com>
Message-ID: <20250408145345.142947-1-adamhet@scaleway.com> Signed-off-by: Stefan Hajnoczi <stefanha@redhat.com>
system/main: transfer replay mutex ownership from main thread to main loop thread
On MacOS, UI event loop has to be ran in the main thread of a process.
Because of that restriction, on this platform, qemu main event loop is
ran on another thread [1].
This breaks record/replay feature, which expects thread running qemu_init
to initialize hold this lock, breaking associated functional tests on
MacOS.
Thus, as a generalization, and similar to how BQL is handled, we release
it after init, and reacquire the lock before entering main event loop,
avoiding a special case if a separate thread is used.
Stefan Hajnoczi [Mon, 14 Apr 2025 15:02:34 +0000 (11:02 -0400)]
Merge tag 'pull-trivial-patches' of https://gitlab.com/mjt0k/qemu into staging
trivial patches for 2025-04-14
# -----BEGIN PGP SIGNATURE-----
#
# iQIzBAABCgAdFiEEZKoqtTHVaQM2a/75gqpKJDselHgFAmf81fEACgkQgqpKJDse
# lHihiBAAlf/FCOGs4qCJuwuoeebI9WC22C+80hQPNMiXLvV7wQWJMqdf6UvPOUt/
# LUdndWrPb2hKKVzcv6mMEKl0wEAxOdxB1FiZZltKwIJiES1OXJcKjNSK84PTN/CN
# WDC/mVjv5v10X7x3xUHTqB1qr6MpWuSQLnfob5u40MVa43wZj6fJPeSYzHsWNgrx
# 47xLlqFyGVv7mMtIxpYsrKoFypNaTTHggSydZnUkOQBIsXvxE9mEagIdNhjGQVNh
# gx76DWxYnjM932yIizKCQJhe2umetlHUR9dUEqWkI8xRA0pQVTE/p5c+rkIxCzeu
# uAadKOOGdRaHKjinyMQMoFTjC6CH8f1znWVwYJvsh2XLyJXb7PAo6jq3piUWLQpv
# OTXSQ2N/1FJeYEkliyjJibabviJpmdY3mzr/Bw0jJh3KYGm1Ub/lGjjaVes5PwHz
# xa5jnm2Dk9sdpWP2VCyxhlffs5iSOQblPBit4UeTyytg1SZohcWNevcz+AdrCUEE
# nYvxQoAl0euq6oAXDV1qsVl7HwgEm9FCiMJY8G94G890wGx9gPIZ+Ofp+9GHbve0
# sxY027EjvosX9Om2IRexmLpwnHRCUYw+09fD8iqs7ie/oN5ryTgYG5oZMAjAZC46
# Rd+dcuxxmT9uc5XZoZaGzloNmCDI7RjMAMAaSlwUMXHB0XA0wc8=
# =VgUD
# -----END PGP SIGNATURE-----
# gpg: Signature made Mon 14 Apr 2025 05:31:29 EDT
# gpg: using RSA key 64AA2AB531D56903366BFEF982AA4A243B1E9478
# gpg: Good signature from "Michael Tokarev <mjt@debian.org>" [unknown]
# gpg: aka "Michael Tokarev <mjt@corpit.ru>" [unknown]
# gpg: aka "Michael Tokarev <mjt@tls.msk.ru>" [unknown]
# gpg: WARNING: This key is not certified with a trusted signature!
# gpg: There is no indication that the signature belongs to the owner.
# Primary key fingerprint: 9D8B E14E 3F2A 9DD7 9199 28F1 61AD 3D98 ECDF 2C8E
# Subkey fingerprint: 64AA 2AB5 31D5 6903 366B FEF9 82AA 4A24 3B1E 9478
* tag 'pull-trivial-patches' of https://gitlab.com/mjt0k/qemu:
docs: Document removal of 64-bit on 32-bit emulation
Fix objdump output parser in "nsis.py"
docs: Fix some typos (found by codespell and typos)
Signed-off-by: Stefan Hajnoczi <stefanha@redhat.com>
Stefan Hajnoczi [Mon, 14 Apr 2025 15:02:09 +0000 (11:02 -0400)]
Merge tag 'pull-10.0-final-fixes-090425-1' of https://gitlab.com/stsquad/qemu into staging
Final fixes for 10.0
- properly exit aarch64-softmmu tcg tests on unexpected exceptions
- fix deadlock when uninstalling a plugin
# -----BEGIN PGP SIGNATURE-----
#
# iQEzBAABCgAdFiEEZoWumedRZ7yvyN81+9DbCVqeKkQFAmf2P+0ACgkQ+9DbCVqe
# KkTHdAf/b4CGLNJBS7UV/eYxhgxJ2TM4KgfXm4FvrcS4V5rpNheMuLoQzgYDY+EC
# 5ioANRcY+rOK2Yd+upO4SbaUyAvf7C5kAtMgs6AYiqbm5F8b47FS/q8f9mBBJ+qB
# tl2FU6hjVjymMRoaPqqpPkkkHy9YNHe48TP4ohGfD6336JA5MW6v8nhdK+d3fsan
# AUCSWAe8gxjmM6qnrhku6vvJ5EOiqpsb8zhsWVXdZesSG+1ATm6KCo6hDd0OkMrk
# si6ML5txU1rxx5VOkGlDUo7ZV2TE/zdgMyaP/kXGtKuj+ipLMzqNjlD50xPJu05b
# o4hTbt8erzxduVHrBKT5qhKQl8BEpw==
# =LN/t
# -----END PGP SIGNATURE-----
# gpg: Signature made Wed 09 Apr 2025 05:37:49 EDT
# gpg: using RSA key 6685AE99E75167BCAFC8DF35FBD0DB095A9E2A44
# gpg: Good signature from "Alex Bennée (Master Work Key) <alex.bennee@linaro.org>" [unknown]
# gpg: WARNING: This key is not certified with a trusted signature!
# gpg: There is no indication that the signature belongs to the owner.
# Primary key fingerprint: 6685 AE99 E751 67BC AFC8 DF35 FBD0 DB09 5A9E 2A44
* tag 'pull-10.0-final-fixes-090425-1' of https://gitlab.com/stsquad/qemu:
tests/tcg/plugins: add plugin to test reset and uninstall
plugins/loader: fix deadlock when resetting/uninstalling a plugin
tests/tcg: fix semihosting SYS_EXIT for aarch64 in boot.S
Signed-off-by: Stefan Hajnoczi <stefanha@redhat.com>
docs: Document removal of 64-bit on 32-bit emulation
With acce728cbc6c we disallowed configuring 64-bit guests on
32-bit hosts, but forgot to document that in removed-features.
Signed-off-by: Richard Henderson <richard.henderson@linaro.org> Reviewed-by: Michael Tokarev <mjt@tls.msk.ru> Reviewed-by: Daniel P. Berrangé <berrange@redhat.com> Reviewed-by: Alex Bennée <alex.bennee@linaro.org> Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>
In msys2 distribution objdump from gcc is using single tab character
prefix, but objdump from clang is using 4 white space characters instead.
The script will not identify any dll dependencies for a QEMU build
generated with clang. This in turn will fail the build, because there
will be no files inside dlldir and no setup file will be created.
Instead of checking for whitespace in prefix use lstrip to accommodate
for differences in outputs.
Signed-off-by: Arthur Sengileyev <arthur.sengileyev@gmail.com> Reviewed-by: Stefan Weil <sw@weilnetz.de> Reviewed-by: Michael Tokarev <mjt@tls.msk.ru> Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>
Alex Bennée [Fri, 4 Apr 2025 11:51:12 +0000 (12:51 +0100)]
tests/tcg: fix semihosting SYS_EXIT for aarch64 in boot.S
We don't expect to hit exceptions in our testing so currently all the
vectors report an un-expected exception and then attempt to exit.
However for aarch64 we should always use the extended information
block as we do in _exit. Rather than duplicate the code on the error
handler just branch to the _exit handler with a failing status code.
Signed-off-by: Alex Bennée <alex.bennee@linaro.org> Reviewed-by: Richard Henderson <richard.henderson@linaro.org>
Message-Id: <20250404115641.258048-1-alex.bennee@linaro.org>
* tag 'hw-misc-20250408' of https://github.com/philmd/qemu:
scripts/checkpatch: Fix typo in SPDX-License-Identifier keyword
hw/nvme: fix attachment of private namespaces
hw/arm/imx8mp-evk: Temporarily remove unimplemented imx8mp-fspi node from devicetree
hw/arm/imx8mp-evk: Remove unimplemented cpu-idle-states properties from devicetree
hw/ufs: Fix incorrect comment for segment_size and allocation_unit_size
docs/arm: Add apple HVF host for supported guest CPU type
hw/core/machine: Fix -machine dumpdtb=file.dtb
smbios: Fix buffer overrun when using path= option
Signed-off-by: Stefan Hajnoczi <stefanha@redhat.com>
Zhao Liu [Tue, 8 Apr 2025 16:27:02 +0000 (00:27 +0800)]
scripts/checkpatch: Fix typo in SPDX-License-Identifier keyword
Fix the typo in the error message to help `grep` the example:
ERROR: New file '***' requires 'SPDX-License-Identifer'
Fixes: fa4d79c64dae ("scripts: mandate that new files have SPDX-License-Identifier") Signed-off-by: Zhao Liu <zhao1.liu@intel.com> Reviewed-by: Alex Bennée <alex.bennee@linaro.org>
Message-ID: <20250408162702.2350565-1-zhao1.liu@intel.com> Signed-off-by: Philippe Mathieu-Daudé <philmd@linaro.org>
projects / thirdparty / qemu.git / log
