HPPA patches for qemu-v11
A few late fixes for the HPPA architecture for QEMU v11:
- graphics support was broken for 64-bit machines. This series adds
support for VGA graphics for Linux guests
- the various memory ranges were not correctly implemented
- TOC/NMI was not working on 64-bit machines
- minor 64-bit HP-UX boot fixes (but HP-UX 64-bit still crashes)
# -----BEGIN PGP SIGNATURE-----
#
# iHUEABYKAB0WIQS86RI+GtKfB8BJu973ErUQojoPXwUCacwXxAAKCRD3ErUQojoP
# X7NxAQCBszDUKsNX5KiB+cxW1AfT1Gyzo4q9T0NNULO5v2Fn7gD/YVzgtZ6F+crK
# 1eG1R0aVekPmx+NClsCLvy/dX1YmTww=
# =L+6i
# -----END PGP SIGNATURE-----
# gpg: Signature made Tue Mar 31 19:51:48 2026 BST
# gpg: using EDDSA key BCE9123E1AD29F07C049BBDEF712B510A23A0F5F
# gpg: Good signature from "Helge Deller <deller@gmx.de>" [unknown]
# gpg: aka "Helge Deller <deller@kernel.org>" [unknown]
# gpg: aka "Helge Deller <deller@debian.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: 4544 8228 2CD9 10DB EF3D 25F8 3E5F 3D04 A7A2 4603
# Subkey fingerprint: BCE9 123E 1AD2 9F07 C049 BBDE F712 B510 A23A 0F5F
* tag 'hppa-more-v11-fixes-pull-request' of https://github.com/hdeller/qemu-hppa:
target/hppa: Update SeaBIOS-hppa to version 24
hw/hppa: Implement memory ranges
target/hppa: Fix TOC handler for 64-bit CPUs
hw/pci-host/astro: Add GMMIO mapping
hw/pci-host/astro: Fix LMMIO DIRECT mappings
hw/pci-host/astro: Implement LMMIO registers
hw/pci-host/astro: Fix initial addresses in IOC
hw/pci-host/astro: Make astro address arrays accessible for other users
Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
New SeaBIOS-hppa v24 release with various fixes for qemu-v11:
- Initialize Astro chip with relevant LMMIO, GMMIO and others
- Disable Artist on 64-bit machines
- Fully implement parisc memory ranges
- Change inventory to list CPU first for HP-UX
- Allow 715 to boot from HP-UX 11iv1 CD-ROM
- Prepare for MULTICELL machines
- Initialize PCI_CACHE_LINE_SIZE PCI value
- Call TOC/HPMC handler code from OS if installed
Signed-off-by: Helge Deller <deller@gmx.de>
All 64-bit PA-RISC machines split the memory into (up to 3) different
memory ranges, which are mapped at specific addresses. This patch
mimics the mapping as it's done on physical machines, which includes the
3.75 GB split for C3700, and 1 GB split for newer 64-bit PAT machines
like the A400.
SeaBIOS-hppa needs to know how the memory split is done, so add a new
memsplit_addr variable which stores the specific split address and hand
this over to SeaBIOS-hppa via fwcfg.
Signed-off-by: Helge Deller <deller@gmx.de>
When the TOC handler is triggered, e.g. by using the "NMI" command
in the QEMU monitor, make sure to call the full 64-bit TOC handler
address in SeaBIOS-hppa firmware.
This fixes the TOC handler on 64-bit CPUs (and 64-bit SeaBIOS).
Signed-off-by: Helge Deller <deller@gmx.de>
Fix the existing code which has the mask wrong.
Implement the direct mapping via overlapping subregion with priority 3
to make sure the direct mapping gets precedence over the LMMIO region.
Signed-off-by: Helge Deller <deller@gmx.de>
Add code to adjust the memory mapping windows according to the LMMIO registers
in Astro. This allows SeaBIOS-hppa to configure Astro depending on existing
PCI cards, and especially makes it possible to enable a VGA PCI card.
Signed-off-by: Helge Deller <deller@gmx.de>
Synchronous signals must accommodate a synchronous signal being
raised during delivery, as asynchronous ones do. For example
badframe errors during delivery will cause SIGSEGV to be raised.
Without this fix, cpu_loop() runs process_pending_signals() which
delivers the first synchronous signal (e.g., SIGILL) which fails
to set the handler and forces SIGSEGV, but that is not picked up.
process_pending_signals() returns. Then cpu_loop() runs cpu_exec()
again, which attempts to execute the same instruction, another
SIGILL.
Signed-off-by: Nicholas Piggin <npiggin@gmail.com>
Reviewed-by: Warner Losh <imp@bsdimp.com>
Reviewed-by: Peter Maydell <peter.maydell@linaro.org>
Message-id: 20260321135624.581398-3-npiggin@gmail.com
Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
openat2() ignored the -L prefix and opened host files directly.
For example, openat2("/tmp/file") opened /tmp/file on the host, not
QEMU_LD_PREFIX/tmp/file like openat() does.
Fix this by using path() to rewrite absolute paths. Skip this
when RESOLVE_BENEATH or RESOLVE_IN_ROOT is set:
- RESOLVE_BENEATH rejects absolute paths anyway
- RESOLVE_IN_ROOT resolves relative to dirfd
Now openat() and openat2() work in the same way.
Link: https://gitlab.com/qemu-project/qemu/-/work_items/3341
Signed-off-by: Sun Haoyu <shyliuli@aosc.io>
Reviewed-by: Peter Maydell <peter.maydell@linaro.org>
Message-id: 20260317053827.25051-1-shyliuli@aosc.io
Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
The Linux kernel writes back the remaining timeout for select-family
syscalls in poll_select_finish(). If that writeback fails, it keeps
the original return value.
However, QEMU only writes back the timeout on success. If the writeback
fails, QEMU returns -TARGET_EFAULT. This can lose the remaining
timeout and change the return value.
Update do_select(), do_pselect6(), and do_ppoll() to always write back
the timeout to match the Linux kernel's behavior. If the timeout
writeback fails, keep the original return value.
Tested with the issue reproducer.
Resolves: https://gitlab.com/qemu-project/qemu/-/work_items/3343
Signed-off-by: Sun Haoyu <shyliuli@aosc.io>
Reviewed-by: Peter Maydell <peter.maydell@linaro.org>
Message-id: 20260320111647.138984-1-shyliuli@aosc.io
Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
In commit 7804c84a ("include/user: Use vaddr in guest-host.h") we
changed all the functions in guest-host.h that took or returned their
guest address argument in type abi_ptr to instead use vaddr.
This introduced regressions for the case of a 32-bit guest and an
address above 2GB for the common situation where the address is a
syscall argument stored in a variable of type 'abi_long'. With
abi_ptr (which will be an unsigned 32-bit type for 32-bit guests),
the address is cast to unsigned 32-bit, and then zero-extended to
64-bits in g2h_untagged_vaddr(). With the switch to vaddr (which is
always a 64-bit unsigned type), the guest address will instead be
sign-extended to 64 bits, which gives the wrong answer.
Fix this by providing two versions of the affected functions: the
standard names (g2h(), g2h_untagged(), guest_addr_valid_untagged(),
guest_range_valid_untagged(), cpu_untagged_addr()) return to using
the logically-correct abi_ptr type; new versions with a _vaddr()
prefix use the vaddr type.
accel/tcg/user-exec.c must change to use the _vaddr() versions; this
is the only file that uses guest-host.h that we want to compile once.
All the other uses are in linux-user and bsd-user code that
inherently has to know the sizes of target-ABI types.
Cc: qemu-stable@nongnu.org
Fixes: 7804c84a ("include/user: Use vaddr in guest-host.h")
Resolves: https://gitlab.com/qemu-project/qemu/-/work_items/3333
Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
Reviewed-by: Laurent Vivier <laurent@vivier.eu>
Reviewed-by: Richard Henderson <richard.henderson@linaro.org>
Message-id: 20260330143123.1685142-3-peter.maydell@linaro.org
Reviewed-by: Philippe Mathieu-Daudé <philmd@linaro.org>
We currently include user/guest-host.h from accel/tcg/cpu-ldst.h.
However that file doesn't need anything from guest-host.h, since we
removed the uses of g2h() in commit 9b74d403b3 ("accel/tcg: Move
user-only tlb_vaddr_to_host out of line").
Move the include of guest-host.h to where it's actually needed.
Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
Reviewed-by: Laurent Vivier <laurent@vivier.eu>
Reviewed-by: Richard Henderson <richard.henderson@linaro.org>
Message-id: 20260330143123.1685142-2-peter.maydell@linaro.org
Reviewed-by: Philippe Mathieu-Daudé <philmd@linaro.org>
Passing an empty list of boundaries to block-latency-histogram-set sets
up a state that leads to a NULL pointer dereference when the next
request should be accounted for. This is not a useful configuration, so
just error out if the user tries to set it.
The crash can easily be reproduced with the following script:
qmp() {
cat <<EOF
{'execute':'qmp_capabilities'}
{'execute':'block-latency-histogram-set',
'arguments': {'id':'ide0','boundaries':[]}}
{'execute':'cont'}
EOF
}
qmp | ./qemu-system-x86_64 -S -qmp stdio \
-drive if=none,format=raw,file=null-co:// \
-device ide-hd,drive=none0,id=ide0
Signed-off-by: Kevin Wolf <kwolf@redhat.com>
Message-ID: <20260331102608.60882-1-kwolf@redhat.com>
Signed-off-by: Kevin Wolf <kwolf@redhat.com>
The QSD vhost-user-blk export sets opt_io_size=1 and min_io_size=1 in
the virtio config. These values are reported to the guest through the
VPD Block Limits page as OptimalTransferLength=1 block (512 bytes)
and OptimalTransferLengthGranularity=1 block.
Windows respects these hints and splits all I/O into ~512-byte
requests, causing ~100x sequential throughput degradation (150 MB/s
instead of 15+ GB/s). Linux is unaffected as its block layer ignores
these values.
Set both to 0 which means "not reported" per the SCSI Block Limits
VPD spec, allowing Windows to use its own optimal I/O size defaults.
Signed-off-by: Max Makarov <maxpain@linux.com>
Message-ID: <20260330193451.76037-1-maxpain@linux.com>
Reviewed-by: Kevin Wolf <kwolf@redhat.com>
Signed-off-by: Kevin Wolf <kwolf@redhat.com>
During qemu_cleanup, if a non-coroutine QMP command (e.g.,
query-commands) is concurrently received and processed by the
mon_iothread, it can lead to a deadlock in monitor_cleanup.
The root cause is a race condition between the main thread's shutdown
sequence and the coroutine's dispatching mechanism. When handling a
non-coroutine QMP command, qmp_dispatcher_co schedules the actual
command execution as a bottom half in iohandler_ctx and then yields. At
this suspended point, qmp_dispatcher_co_busy remains true.
Subsequently, the main thread in monitor_cleanup(), sets
qmp_dispatcher_co_shutdown, and calls qmp_dispatcher_co_wake(). Since
qmp_dispatcher_co_busy is already true, the aio_co_wake is skipped. The
main thread then enters the AIO_WAIT_WHILE_UNLOCKED loop, it executes
the scheduled BH (do_qmp_dispatch_bh) via aio_poll(iohandler_ctx,
false), which attempts to wake up the coroutine, aio_co_wake schedules a
new wake-up BH in iohandler_ctx. The main thread then blocks
indefinitely in aio_poll(qemu_aio_context, true), while the coroutine's
wake-up BH is starved in iohandler_ctx, qmp_dispatcher_co never reaches
termination, resulting in a deadlock.
The execution sequence is illustrated below:
IO Thread Main Thread (qemu_aio_context) qmp_dispatcher_co (iohandler_ctx)
| | |
|-- query-commands | |
|-- qmp_dispatcher_co_wake() | |
| (sets busy = true) | |
| | <-- Wakes up in iohandler_ctx --> |
| | |-- qmp_dispatch()
| | |-- Schedules BH (do_qmp_dispatch_bh)
| | |-- qemu_coroutine_yield()
| | [State: Suspended, busy=true]
| [ quit triggered ] |
| |-- monitor_cleanup()
| |-- qmp_dispatcher_co_shutdown = true
| |-- qmp_dispatcher_co_wake()
| | -> Checks busy flag. It's TRUE!
| | -> Skips aio_co_wake().
| |
| |-- AIO_WAIT_WHILE_UNLOCKED:
| | |-- aio_poll(iohandler_ctx, false)
| | | -> Executes do_qmp_dispatch_bh
| | | -> Schedules 'co_schedule_bh' in iohandler_ctx
| | |
| | |-- aio_poll(qemu_aio_context, true)
| | | -> Blocks indefinitely! (Deadlock)
| |
| X (Main thread sleeping) X (Waiting for next iohandler_ctx poll)
To fix this, we add an explicit aio_wait_kick() in do_qmp_dispatch_bh()
to break the main loop out of its blocking poll, allowing it to evaluate
the loop condition and poll iohandler_ctx.
Suggested-by: Kevin Wolf <kwolf@redhat.com>
Signed-off-by: hongmianquan <hongmianquan@bytedance.com>
Signed-off-by: wubo.bob <wubo.bob@bytedance.com>
Message-ID: <20260327131024.51947-1-hongmianquan@bytedance.com>
Acked-by: Markus Armbruster <armbru@redhat.com>
Reviewed-by: Kevin Wolf <kwolf@redhat.com>
Signed-off-by: Kevin Wolf <kwolf@redhat.com>
The original Artist graphics used the GSC bus, was often installed in old
32-bit machines (e.g. 715) and can not be used on 64-bit machines.
This is why this patch makes the artist driver dependend on the Lasi chip,
which was never used in a 64-bit machine.
Note that there exists a variant of Artist for the PCI-bus (Visualize-EG PCI).
It has quite some differences in the registers, and would require that we write
a PCI ROM for it, so that Linux and HP-UX would be able to use it.
Instead, for now, users can simply use a standard VGA or ATI PCI graphics card
on Linux. This can be enabled on the command line with "-device ati-vga" or
"-device VGA". If the "-nographic" option is omitted, a PCI OCHI controller
with USB keyboard and USB mouse will be added automatically.
This fixes graphics support on 64-bit hppa machines and allows us to boot up a
64-bit Linux installation with VGA graphics.
Signed-off-by: Helge Deller <deller@gmx.de>
Reviewed-by: Philippe Mathieu-Daudé <philmd@linaro.org>
Message-ID: <20260330211859.19317-3-deller@kernel.org>
Signed-off-by: Philippe Mathieu-Daudé <philmd@linaro.org>
Update the link to the documentation, which was still pointing to the
Wiki page. In the meantime the PA-RISC wiki was converted to a
read-the-docs website.
Signed-off-by: Helge Deller <deller@gmx.de>
Reviewed-by: Philippe Mathieu-Daudé <philmd@linaro.org>
Tested-by: Philippe Mathieu-Daudé <philmd@linaro.org>
Message-ID: <20260330211859.19317-2-deller@kernel.org>
Signed-off-by: Philippe Mathieu-Daudé <philmd@linaro.org>
In x86_cpu_get_supported_feature_word() we figure out the supported
features differently for each accelerator. The default case is
"set all feature bits"; however this triggers a warning because
it enables two features which conflict with each other:
$ ./build/x86/qemu-system-x86_64 -cpu max -accel qtest -S
qemu-system-x86_64: warning: this feature conflicts with APX: CPUID[eax=07h,ecx=00h].EBX.mpx [bit 14]
qemu-system-x86_64: warning: this feature conflicts with MPX: CPUID[eax=07h,ecx=01h].EDX.apxf [bit 21]
Treat qtest like TCG here, to avoid the complaint.
Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
Reviewed-by: Zhao Liu <zhao1.liu@intel.com>
Reviewed-by: Philippe Mathieu-Daudé <philmd@linaro.org>
Reviewed-by: Zhao Liu <zhao1.liu@intel.com>
Message-ID: <20260330151437.1787008-1-peter.maydell@linaro.org>
Signed-off-by: Philippe Mathieu-Daudé <philmd@linaro.org>
Fix a minor error in the grammar of the warning messages
produced if both MPX and APX are enabled:
$ ./build/x86/qemu-system-x86_64 -cpu max -accel qtest -S
qemu-system-x86_64: warning: this feature conflicts with APX: CPUID[eax=07h,ecx=00h].EBX.mpx [bit 14]
qemu-system-x86_64: warning: this feature conflicts with MPX: CPUID[eax=07h,ecx=01h].EDX.apxf [bit 21]
Fixes: 91bc4d8107 ("i386/cpu: Add APX EGPRs into xsave area")
Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
Reviewed-by: Zhao Liu <zhao1.liu@intel.com>
Reviewed-by: Philippe Mathieu-Daudé <philmd@linaro.org>
Message-ID: <20260330151309.1786787-1-peter.maydell@linaro.org>
Signed-off-by: Philippe Mathieu-Daudé <philmd@linaro.org>
The MIPS R4K CP0 timer (env->timer) is not included in vmstate_mips_cpu,
so after loadvm the QEMUTimer has no scheduled expiry. This causes
qemu_poll_ns() to block indefinitely and the guest to freeze until an
external I/O event (e.g. a keypress) wakes the main loop.
Fix by adding an optional vmstate subsection for the timer, following
the same pattern used by ARM (gt_timer), RISC-V (env.stimer), SPARC
(qtimer), and OpenRISC (timer).
The .needed callback returns false when env->timer is NULL (KVM mode),
keeping the subsection optional for backwards compatibility with
existing snapshots.
Resolves: https://gitlab.com/qemu-project/qemu/-/issues/1987
Signed-off-by: Trieu Huynh <vikingtc4@gmail.com>
Reviewed-by: Peter Maydell <peter.maydell@linaro.org>
Reviewed-by: Philippe Mathieu-Daudé <philmd@linaro.org>
Message-ID: <20260329113732.482619-1-vikingtc4@gmail.com>
Signed-off-by: Philippe Mathieu-Daudé <philmd@linaro.org>
When commit bdf9613b introduced scsi_sense_buf_is_guest_recoverable(),
it included LOGICAL UNIT NOT SUPPORTED in the list of guest recoverable
sense codes. It doesn't really explain how the codes to be in the list
were selected.
As the LUN doesn't come from the guest, but from the block backend
(usually the SCSI device on the host that was opened with host_device,
but it could also be the iscsi block driver), there is really no way the
guest could influence this.
It seems that on some storage arrays, LOGICAL UNIT NOT SUPPORTED can
happen during failover operations. When combined with multipath, the
request should be retried on another path instead of being reported to
the guest, which would offline the filesystem in response.
Simply returning false in scsi_sense_buf_is_guest_recoverable() will
enable the retry logic in file-posix, and will also make sure that if
the error persists, the configured error policy is respected so that the
VM can be stopped.
Buglink: https://redhat.atlassian.net/browse/RHEL-158212
Fixes: bdf9613b7f ('scsi: explicitly list guest-recoverable sense codes')
Signed-off-by: Kevin Wolf <kwolf@redhat.com>
Message-ID: <20260330121635.49205-1-kwolf@redhat.com>
Reviewed-by: Paolo Bonzini <pbonzini@redhat.com>
Reviewed-by: Stefan Hajnoczi <stefanha@redhat.com>
Signed-off-by: Kevin Wolf <kwolf@redhat.com>
ide_sector_read() as well as its callers neglect to call ide_set_retry()
before starting I/O. If the I/O fails, this means that the retry
information is stale. In particular, ide_handle_rw_error() has an
assertion that s->bus->retry_unit == s->unit, which can fail if either
there was no previous request or it came from another device on the bus.
If the assertion weren't there, a wrong request would be retried after
resuming the VM.
Fix this by adding a ide_set_retry() call to ide_sector_read().
This affects only reads because ide_transfer_start() does call
ide_set_retry(). For writes, the data transfer comes first and the I/O
is only started when the data has been read into s->io_buffer, so by
that time, ide_set_retry() has been called. For reads, however, the I/O
comes first and only then the data is transferred to the guest, so the
call in ide_transfer_start() is too late.
Buglink: https://redhat.atlassian.net/browse/RHEL-153537
Reported-by: Tingting Mao <timao@redhat.com>
Signed-off-by: Kevin Wolf <kwolf@redhat.com>
Message-ID: <20260326165124.138593-1-kwolf@redhat.com>
Signed-off-by: Kevin Wolf <kwolf@redhat.com>
In zynq_set_boot_mode() where we parse the string the user has set
the boot-mode option to, we use strncasecmp(str, "qspi", 4) and so
on. This is wrong, because it means that we will ignore any trailing
junk on the end of the option string, and handle
-machine boot-mode=sdXYZZY
the same as
-machine boot-mode=sd
In the documentation we say:
Supported values are ``jtag``, ``sd``, ``qspi`` and ``nor``.
and that's obviously what we meant to implement.
The correct tool for this job is a simple strcasecmp operation.
Switch to that.
We use the g_ascii_strcasecmp() rather than plain strcasecmp()
because we're comparing ASCII strings here and don't want the
potentially locale-specific behaviour that strcasecmp() implies (and
we're trying to standardize on the glib function for this kind of
string comparison).
Fixes: 7df3747c92 ("hw/arm/xilinx_zynq: Add boot-mode property")
Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
Reviewed-by: Alistair Francis <alistair.francis@wdc.com>
Reviewed-by: Kostiantyn Kostiuk <kkostiuk@redhat.com>
Reviewed-by: Paolo Bonzini <pbonzini@redhat.com>
Message-id: 20260327145012.907264-1-peter.maydell@linaro.org
Riku Voipio doesn't wish to be listed in MAINTAINERS any more;
remove his email from the relevant sections.
This moves the "overall usermode emulation" section to Orphan status.
Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
Message-id: 20260323134741.4114629-2-peter.maydell@linaro.org
In of_dpa_cmd_add_l2_flood(), we allocate memory for the
group->l2_flood.group_ids array, freeing any previous array.
However, in the error-exit path we free the group_ids memory but do
not clear the pointer to NULL. This means that if the guest causes
us to take the error-exit path and then later call the function
again, we will try again to free the memory we already freed.
Fix this by clearing the group_ids pointer in the error exit
path, so we maintain the invariant of "either it points at
allocated memory, or it is NULL" (both being valid to g_free()).
Cc: qemu-stable@nongnu.org
Fixes: dc488f8880 ("rocker: add new rocker switch device")
Resolves: https://gitlab.com/qemu-project/qemu/-/work_items/3253
Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
Reviewed-by: Philippe Mathieu-Daudé <philmd@linaro.org>
Message-id: 20260324193530.375628-1-peter.maydell@linaro.org
As per the pseudo code from DDI0487 M.a.a (on J1-16021) AArch64.S1Walk():
// Check descriptor AF bit
elsif (descriptor<10> == '0' && walkparams.ha == '0' &&
(!accdesc.acctype IN {AccessType_DC, AccessType_IC} ||
boolean IMPLEMENTATION_DEFINED "Generate access flag fault on IC/DC operations")) then
fault.statuscode = Fault_AccessFlag;
an access flag fault should be generated for AccessType_AT, if the AF bit
is 0 and !param.ha.
Besides, we should continue to not raise the access flag fault for
in_debug = true which is what we've been doing previously (before commit
efebeec13d) for LPAE and is what intention of the debugger access
codepath is.
Cc: qemu-stable@nongnu.org
Fixes: efebeec13d ("target/arm: Skip AF and DB updates for AccessType_AT")
Signed-off-by: Zenghui Yu <zenghui.yu@linux.dev>
Message-id: 20260324160321.96347-1-zenghui.yu@linux.dev
Reviewed-by: Peter Maydell <peter.maydell@linaro.org>
Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
After the referenced commit, the incoming side doesn't exit
automatically after a failure. Tests that expect the destination to
fail should use -incoming defer, issue QMP migrate-incoming, wait for
the failure event and issue QMP quit.
Fix the dirty_limit test which wasn't updated properly.
Fixes: 4e8c4dda97 ("tests/qtest/migration: Force exit-on-error=false")
Reported-by: Thomas Huth <thuth@redhat.com>
Reviewed-by: Peter Xu <peterx@redhat.com>
Link: https://lore.kernel.org/qemu-devel/20260326164405.1626-1-farosas@suse.de
Signed-off-by: Fabiano Rosas <farosas@suse.de>
