On Windows, we run QGA with `-d --retry-path` options by default,
and expect that QGA will start even without the vioserial driver
and will wait for communication forever.
Reviewed-by: Yan Vugenfirer <yvugenfi@redhat.com>
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
Link: https://lore.kernel.org/qemu-devel/20250825140549.146617-3-kkostiuk@redhat.com
Signed-off-by: Kostiantyn Kostiuk <kkostiuk@redhat.com>
In this function we could have this variable not initialized. If this
could be acceptable on error, the variable could be left not initialized
f.e. as follows:
void requester_freeze(int *num_vols, void *mountpoints, ErrorSet *errset)
{
...
if (mountpoints) {
...
if (num_mount_points == 0) {
/* If there is no valid mount points, just exit. */
goto out;
}
}
...
if (!mountpoints) {
...
if (num_fixed_drives == 0) {
goto out; /* If there is no fixed drive, just exit. */
}
}
...
}
Stay on safe side, initialize the variable at the beginning.
Signed-off-by: Denis V. Lunev <den@openvz.org>
CC: Kostiantyn Kostiuk <kkostiuk@redhat.com>
CC: Michael Roth <michael.roth@amd.com>
Reviewed-by: Kostiantyn Kostiuk <kkostiuk@redhat.com>
Link: https://lore.kernel.org/qemu-devel/20250807133221.1135453-1-den@openvz.org
Signed-off-by: Kostiantyn Kostiuk <kkostiuk@redhat.com>
When compiling QEMU with --enable-ubsan there is a undefined behavior
warning when running "make check":
.../qga/commands-linux.c:452:15: runtime error: applying non-zero offset 5 to null pointer
#0 0x55ea7b89450c in build_guest_fsinfo_for_pci_dev ..../qga/commands-linux.c:452:15
Fix it by avoiding the additional pointer variable here and use an
"offset" integer variable instead.
Signed-off-by: Thomas Huth <thuth@redhat.com>
Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>
Reviewed-by: Kostiantyn Kostiuk <kkostiuk@redhat.com>
Link: https://lore.kernel.org/qemu-devel/20250730072709.27077-1-thuth@redhat.com
Signed-off-by: Kostiantyn Kostiuk <kkostiuk@redhat.com>
This reverts commit 00268e0002.
(The only conflict is in the !is_tdx_vm() part of the condition,
which is safe to keep).
mark_unavailable_features() actively blocks usage of the feature,
so it is a functional change, not merely a emitting warning.
The commit was intended to merely warn if PDCM was enabled when
the performance counters are not, so revert it.
Reported-by: Christian A. Ehrhardt <christian.ehrhardt@canonical.com>
Analyzed-by: Daniel P. Berrangé <berrange@redhat.com>
Analyzed-by: Xiaoyao Li <xiaoyao.li@intel.com>
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>
Message-ID: <20250819150235.785559-1-pbonzini@redhat.com>
Signed-off-by: Stefan Hajnoczi <stefanha@redhat.com>
- configure: Don't disable Rust for too old meson version
- rbd: Fix hang in query-named-block-nodes if the server is down
- iotests: Fix reference output for newer bash versions
-----BEGIN PGP SIGNATURE-----
iQJFBAABCgAvFiEE3D3rFZqa+V09dFb+fwmycsiPL9YFAmiblrYRHGt3b2xmQHJl
ZGhhdC5jb20ACgkQfwmycsiPL9Z3UQ//Xl3LZP4ZHScc16X4vDhH/4eru9Yu5zz/
k2kWqmns6aClUZXplfWPKnM5a47b/23ZiM7MaxhgTolShtFPAODP0dDxAaPJSCJD
EjhMbTB8u4GeMCe7T4HqGY/UHcGDWGzD9Ne5ssxt8yRT3fkuM/XxTptlIT93Rz9w
bjTuCnctP6pGWW3za67bUdr9ZzwpmMXvXwpcXrlhKCqq+qbpHK8/rTp2yaNF5Pi9
3K+uITLOVk04UL1JbSgXgvId5JSBDE0JnPDFPhhkAcliQJKR3W3iWhIKwA4rvnZ5
dzAMNk3TafzUsZp+k9gPXdQ/+km3Hj17vyHLEoEk0cPVoNi+ZbpKCij15O6OPKAn
OP6aznanat8W8hQh+2lv29fLyYICZpXbsEGB7X7Kfz4uf4BhhopHHvq6SOnZwO14
MaUjVEO7kBWHgXH3o8PzyHsZq7oWQdEZuKhcnemMb5+6ngLoGX1N1zZUGAcuaar+
31rePhgWprdOfZEW9X46i6AKff3xWHl5yQ9jQMPZWNwiYXNemh4oZXSYsgVbvNHd
g73d/4G5iUt61fg6CtyqFDDa4/1WP0jU4164p6kcvYJVj1HaKy3FrAVrOfINbFFy
dX3jCECkd52ilBwWisDWSWUqh2S09LJrn7O7FZUwYySivINuajZWwJYuDdxRvyc6
q7Qg7ocWaQ8=
=goPX
-----END PGP SIGNATURE-----
Merge tag 'for-upstream' of git://repo.or.cz/qemu/kevin into staging
Patches for QEMU 10.1.0-rc3
- configure: Don't disable Rust for too old meson version
- rbd: Fix hang in query-named-block-nodes if the server is down
- iotests: Fix reference output for newer bash versions
# -----BEGIN PGP SIGNATURE-----
#
# iQJFBAABCgAvFiEE3D3rFZqa+V09dFb+fwmycsiPL9YFAmiblrYRHGt3b2xmQHJl
# ZGhhdC5jb20ACgkQfwmycsiPL9Z3UQ//Xl3LZP4ZHScc16X4vDhH/4eru9Yu5zz/
# k2kWqmns6aClUZXplfWPKnM5a47b/23ZiM7MaxhgTolShtFPAODP0dDxAaPJSCJD
# EjhMbTB8u4GeMCe7T4HqGY/UHcGDWGzD9Ne5ssxt8yRT3fkuM/XxTptlIT93Rz9w
# bjTuCnctP6pGWW3za67bUdr9ZzwpmMXvXwpcXrlhKCqq+qbpHK8/rTp2yaNF5Pi9
# 3K+uITLOVk04UL1JbSgXgvId5JSBDE0JnPDFPhhkAcliQJKR3W3iWhIKwA4rvnZ5
# dzAMNk3TafzUsZp+k9gPXdQ/+km3Hj17vyHLEoEk0cPVoNi+ZbpKCij15O6OPKAn
# OP6aznanat8W8hQh+2lv29fLyYICZpXbsEGB7X7Kfz4uf4BhhopHHvq6SOnZwO14
# MaUjVEO7kBWHgXH3o8PzyHsZq7oWQdEZuKhcnemMb5+6ngLoGX1N1zZUGAcuaar+
# 31rePhgWprdOfZEW9X46i6AKff3xWHl5yQ9jQMPZWNwiYXNemh4oZXSYsgVbvNHd
# g73d/4G5iUt61fg6CtyqFDDa4/1WP0jU4164p6kcvYJVj1HaKy3FrAVrOfINbFFy
# dX3jCECkd52ilBwWisDWSWUqh2S09LJrn7O7FZUwYySivINuajZWwJYuDdxRvyc6
# q7Qg7ocWaQ8=
# =goPX
# -----END PGP SIGNATURE-----
# gpg: Signature made Tue 12 Aug 2025 15:32:06 EDT
# gpg: using RSA key DC3DEB159A9AF95D3D7456FE7F09B272C88F2FD6
# gpg: issuer "kwolf@redhat.com"
# gpg: Good signature from "Kevin Wolf <kwolf@redhat.com>" [full]
# Primary key fingerprint: DC3D EB15 9A9A F95D 3D74 56FE 7F09 B272 C88F 2FD6
* tag 'for-upstream' of git://repo.or.cz/qemu/kevin:
qemu-iotests: Ignore indentation in Killed messages
rbd: Fix .bdrv_get_specific_info implementation
configure: Don't disable Rust for too old meson version
Signed-off-by: Stefan Hajnoczi <stefanha@redhat.com>
The temporary egl fb scanout_tex_fb is only needed to facilitate the
blit to the display surface's texture (ssd->ds->texture). Therefore,
destroy it after the blit is submitted. And, also make sure that it
is empty initialized before it is actually used.
Fixes: f851cd65 ("ui/spice: Blit the scanout texture if its memory layout is not linear")
Reported-by: Peter Maydell <peter.maydell@linaro.org>
Cc: Marc-André Lureau <marcandre.lureau@redhat.com>
Signed-off-by: Vivek Kasireddy <vivek.kasireddy@intel.com>
Reviewed-by: Marc-André Lureau <marcandre.lureau@redhat.com>
Message-ID: <20250718234039.2266704-1-vivek.kasireddy@intel.com>
Signed-off-by: Stefan Hajnoczi <stefanha@redhat.com>
We don't build the PDFs ourselves for the hosted docs and it looks
like rtd can't manage building PDFs now they have gone over a certain
size. Disable the extra formats so we can at least have the online
stuff again.
Signed-off-by: Alex Bennée <alex.bennee@linaro.org>
Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>
Message-ID: <20250804162959.330060-1-alex.bennee@linaro.org>
Signed-off-by: Stefan Hajnoczi <stefanha@redhat.com>
Fix compilation with pip-25.2 due to missing distlib.version
Bug: https://gitlab.com/qemu-project/qemu/-/issues/3062
Signed-off-by: Sv. Lockal <lockalsash@gmail.com>
[Edits: Type "safety" whackamole --js]
Signed-off-by: John Snow <jsnow@redhat.com>
Message-ID: <20250811190159.237321-1-jsnow@redhat.com>
Signed-off-by: Stefan Hajnoczi <stefanha@redhat.com>
SPI-SD adapter should be usable, even without any SD card
wired. Refactor test_riscv64_sifive_u_mmc_spi() to make it
more generic and add another test, inspired by this report:
https://lore.kernel.org/qemu-devel/5b2dc427-f0db-4332-a997-fe0c82415acd@roeck-us.net/
Inspired-by: Guenter Roeck <linux@roeck-us.net>
Signed-off-by: Philippe Mathieu-Daudé <philmd@linaro.org>
Reviewed-by: Gustavo Romero <gustavo.romero@linaro.org>
Reviewed-by: Alex Bennée <alex.bennee@linaro.org>
Tested-by: Alex Bennée <alex.bennee@linaro.org>
Message-Id: <20250812140415.70153-3-philmd@linaro.org>
Commit 1585ab9f1b ("hw/sd/sdcard: Fill SPI response bits in card
code") exposed a bug in the SPI adapter: if no SD card is plugged,
we are returning "there is a card with an error". This is wrong,
we shouldn't return any particular packet response, but the noise
shifted on the MISO line. Return the dummy byte, otherwise we get:
qemu-system-riscv64: ../hw/sd/ssi-sd.c:160: ssi_sd_transfer: Assertion `s->arglen > 0' failed.
Reported-by: Guenter Roeck <linux@roeck-us.net>
Fixes: 775616c3ae ("Partial SD card SPI mode support")
Signed-off-by: Philippe Mathieu-Daudé <philmd@linaro.org>
Tested-by: Guenter Roeck <linux@roeck-us.net>
Reviewed-by: Alex Bennée <alex.bennee@linaro.org>
Reviewed-by: Gustavo Romero <gustavo.romero@linaro.org>
Tested-by: Alex Bennée <alex.bennee@linaro.org>
Message-Id: <20250812140415.70153-2-philmd@linaro.org>
New bash 5.3 uses a different padding for reporting job status.
Resolves: boo#1246830
Resolves: https://gitlab.com/qemu-project/qemu/-/issues/3050
Signed-off-by: Werner Fink <werner@suse.de>
Message-ID: <aJL8RH8ePPNEteMg@boole.nue2.suse.org>
Reviewed-by: Kevin Wolf <kwolf@redhat.com>
Tested-by: Martin Kletzander <mkletzan@redhat.com>
Signed-off-by: Kevin Wolf <kwolf@redhat.com>
qemu_rbd_get_specific_info() has at least two problems:
The first is that it issues a blocking rbd_read() call in order to probe
the encryption format for the image while querying the node. This means
that if the connection to the server goes down, not only I/O is stuck
(which is unavoidable), but query-names-block-nodes will actually make
the whole QEMU instance unresponsive. .bdrv_get_specific_info
implementations shouldn't perform blocking operations, but only return
what is already known.
The second is that the information returned isn't even correct. If the
image is already opened with encryption enabled at the RBD level, we'll
probe for "double encryption", i.e. if the encrypted data contains
another encryption header. If it doesn't (which is the normal case), we
won't return the encryption format. If it does, we return misleading
information because it looks like we're talking about the outer level
(the encryption format of the image itself) while the information is
about an encryption header in the guest data.
Fix this by storing the encryption format in BDRVRBDState when the image
is opened (and we do blocking operations anyway) and returning only the
stored information in qemu_rbd_get_specific_info().
The information we'll store is either the actual encryption format that
we enabled on the RBD level, or if the image is unencrypted, the result
of the same probing as we previously did when querying the node. Probing
image formats based on content that can be modified by the guest has
long been known as problematic, but as long as we only output it to the
user instead of making decisions based on it, it should be okay. It is
undoubtedly useful in the context of 'qemu-img info' when you're trying
to figure out which encryption options you have to use to open the
image successfully.
Fixes: 42e4ac9ef5 ("block/rbd: Add support for rbd image encryption")
Buglink: https://issues.redhat.com/browse/RHEL-105440
Signed-off-by: Kevin Wolf <kwolf@redhat.com>
Message-ID: <20250811134010.81787-1-kwolf@redhat.com>
Reviewed-by: Hanna Czenczek <hreitz@redhat.com>
Signed-off-by: Kevin Wolf <kwolf@redhat.com>
If the user explicitly specified --enable-rust, don't just fail if meson
is too old for Rust support, but do the same thing as if meson was too
old for the C code: Just download a newer one.
In order to avoid the additional download for people who aren't
intentionally opting in to Rust, keep the automatic disabling based on
the meson version as the default if neither --enable-rust nor
--disable-rust were given.
Signed-off-by: Kevin Wolf <kwolf@redhat.com>
Message-ID: <20250811142923.89983-1-kwolf@redhat.com>
Reviewed-by: Paolo Bonzini <pbonzini@redhat.com>
Signed-off-by: Kevin Wolf <kwolf@redhat.com>
Fixes file length discrepancies due to line ending conversions
on windows hosts.
Resolves: https://gitlab.com/qemu-project/qemu/-/issues/3058
Reviewed-by: Philippe Mathieu-Daudé <philmd@linaro.org>
Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
Message-ID: <20250811130110.820958-4-kraxel@redhat.com>
When listing variables (via get-next-variable-name) only the names of
variables which can be accessed will be returned. That check was
missing for the first variable though. Add it.
Reviewed-by: Philippe Mathieu-Daudé <philmd@linaro.org>
Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
Message-ID: <20250811130110.820958-3-kraxel@redhat.com>
Set status to SUCCESS for ready-to-boot and exit-boot-services
notification calls.
Reviewed-by: Philippe Mathieu-Daudé <philmd@linaro.org>
Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
Message-ID: <20250811130110.820958-2-kraxel@redhat.com>
When the guest writes to register UEFI_VARS_REG_BUFFER_SIZE, the .write
callback `uefi_vars_write` is invoked. The function allocates a
heap buffer without zeroing the memory, leaving the buffer filled with
residual data from prior allocations. When the guest later reads from
register UEFI_VARS_REG_PIO_BUFFER_TRANSFER, the .read callback
`uefi_vars_read` returns leftover metadata or other sensitive process
memory from the previously allocated buffer, leading to an information
disclosure vulnerability.
Fixes: CVE-2025-8860
Fixes: 90ca4e03c2 ("hw/uefi: add var-service-core.c")
Reported-by: ZDI <zdi-disclosures@trendmicro.com>
Suggested-by: Gerd Hoffmann <kraxel@redhat.com>
Signed-off-by: Mauro Matteo Cascella <mcascell@redhat.com>
Message-ID: <20250811101128.17661-1-mcascell@redhat.com>
Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
Debian trixie has been released. The "stable" alias no longer refers to
the Debian bookworm release, so URLs referring to bookworm artifacts via
the "stable" alias no longer work.
Switch to explicit release naming ("bookworm") to make a permalink so
the test passes again.
Suggested-by: Peter Maydell <peter.maydell@linaro.org>
Fixes: 374a245573 ("tests/functional: Add PCI hotplug test for aarch64")
Resolves: #3073 ("PCI hotplug test for aarch64 fails due to broken Debian installer URL")
Reviewed-by: Alex Bennée <alex.bennee@linaro.org>
Reviewed-by: Philippe Mathieu-Daudé <philmd@linaro.org>
Tested-by: Philippe Mathieu-Daudé <philmd@linaro.org>
Reviewed-by: Peter Maydell <peter.maydell@linaro.org>
Message-ID: <20250811162315.59997-1-stefanha@redhat.com>
Signed-off-by: Stefan Hajnoczi <stefanha@redhat.com>
The emulated device had let the user set whatever max transfers size
they wanted, including no limit. However the device does have an
internal limit of 1024 segments. NVMe doesn't report max segments,
though. This is implicitly inferred based on the MDTS and MPSMIN values.
IOV_MAX is currently 1024 which 4k PRPs can exceed with 2MB transfers.
Don't allow MDTS values that can exceed this, otherwise users risk
seeing "internal error" status to their otherwise protocol compliant
commands.
Signed-off-by: Keith Busch <kbusch@kernel.org>
Signed-off-by: Klaus Jensen <k.jensen@samsung.com>
Commit cd59f50ab0 ("hw/nvme: always initialize a subsystem") causes
the controller to always set the CMIC.MCTRS ("Multiple Controllers")
bit. While spec-compliant, this is a deviation from the previous
behavior where this was only set if an nvme-subsys device was explicitly
created (to configure a subsystem with multiple controllers/namespaces).
Revert the behavior to only set CMIC.MCTRS if an nvme-subsys device is
created explicitly.
Reported-by: Alan Adamson <alan.adamson@oracle.com>
Fixes: cd59f50ab0 ("hw/nvme: always initialize a subsystem")
Reviewed-by: Alan Adamson <alan.adamson@oracle.com>
Tested-by: Alan Adamson <alan.adamson@oracle.com>
Signed-off-by: Klaus Jensen <k.jensen@samsung.com>
Commit 6ccca4b6bb ("hw/nvme: rework csi handling") introduced a bug in
Namespace Attachment, causing it to
a) not allow a controller to attach namespaces to other controllers
b) assert if a valid non-attached namespace is detached
This fixes both issues.
Fixes: 6ccca4b6bb ("hw/nvme: rework csi handling")
Resolves: https://gitlab.com/qemu-project/qemu/-/issues/2976
Reviewed-by: Jesper Wendel Devantier <foss@defmacro.it>
Signed-off-by: Klaus Jensen <k.jensen@samsung.com>
The new QAPI code generator creates a cross-reference target for each
definition documentation. Enabled for the QEMU QMP Reference manual
in commit a377f39f38, and for the QEMU Storage Daemon QMP Reference
Manual and the QEMU Guest Agent Protocol Reference in commit
a6af544344. We've put these targets to use since, but neglected to
update doc comment markup documentation. Do that now.
Co-developed-by: John Snow <jsnow@redhat.com>
Signed-off-by: John Snow <jsnow@redhat.com>
Signed-off-by: Markus Armbruster <armbru@redhat.com>
Message-ID: <20250731054044.4011789-4-armbru@redhat.com>
Fixes: 3248c1aaf2 (docs: update the documentation upfront about schema configuration)
Signed-off-by: Markus Armbruster <armbru@redhat.com>
Message-ID: <20250731054044.4011789-3-armbru@redhat.com>
Reviewed-by: John Snow <jsnow@redhat.com>
Commit 350785d41d ("ramfb: Add property to control if load the
romfile") introduced the `use-legacy-x86-rom` property for the
`vfio-pci-nohotplug` device. Add documentation for the property.
Fixes: d5fcf0d960 ("hw/i386: Add the ramfb romfile compatibility")
Reviewed-by: Philippe Mathieu-Daudé <philmd@linaro.org>
Link: https://lore.kernel.org/qemu-devel/20250805065543.120091-1-clg@redhat.com
Signed-off-by: Cédric Le Goater <clg@redhat.com>
cpr-transfer may lose a VFIO interrupt because the KVM instance is
destroyed and recreated. If an interrupt arrives in the middle, it is
dropped. To fix, stop pending new interrupts during cpr save, and pick
up the pieces. In more detail:
Stop the VCPUs. Call kvm_irqchip_remove_irqfd_notifier_gsi --> KVM_IRQFD to
deassign the irqfd gsi that routes interrupts directly to the VCPU and KVM.
After this call, interrupts fall back to the kernel vfio_msihandler, which
writes to QEMU's kvm_interrupt eventfd. CPR already preserves that
eventfd. When the route is re-established in new QEMU, the kernel tests
the eventfd and injects an interrupt to KVM if necessary.
Deassign INTx in a similar manner. For both MSI and INTx, remove the
eventfd handler so old QEMU does not consume an event.
If an interrupt was already pended to KVM prior to the completion of
kvm_irqchip_remove_irqfd_notifier_gsi, it will be recovered by the
subsequent call to cpu_synchronize_all_states, which pulls KVM interrupt
state to userland prior to saving it in vmstate.
Signed-off-by: Steve Sistare <steven.sistare@oracle.com>
Reviewed-by: Zhenzhong Duan <zhenzhong.duan@intel.com>
Link: https://lore.kernel.org/qemu-devel/1752689169-233452-3-git-send-email-steven.sistare@oracle.com
Signed-off-by: Cédric Le Goater <clg@redhat.com>
According to the specification, [X]VLDI should trigger an invalid instruction
exception only when Bit[12] is 1 and Bit[11:8] > 12. This patch fixes an issue
where an exception was incorrectly raised even when Bit[12] was 0.
Test case:
```
.global main
main:
vldi $vr0, 3328
ret
```
Reported-by: Zhou Qiankang <wszqkzqk@qq.com>
Signed-off-by: WANG Rui <wangrui@loongson.cn>
Reviewed-by: Song Gao <gaosong@loongson.cn>
Message-ID: <20250804132212.4816-1-wangrui@loongson.cn>
Signed-off-by: Song Gao <gaosong@loongson.cn>
brlapi__openConnection returns a brlapi_fileDescriptor which is a pointer
for Windows builds.
The test for brlapi fails with cross builds on Debian trixie
(x86_64-w64-mingw32-gcc (GCC) 14-win32):
testfile.c:4:30: error: returning 'brlapi_fileDescriptor' {aka 'void *'} from a function with return type 'int' makes integer from pointer without a cast [-Wint-conversion]
4 | int main(void) { return brlapi__openConnection (NULL, NULL, NULL); }
| ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
-----------
../../../meson.build:1607: WARNING: could not link brlapi, disabling
Signed-off-by: Stefan Weil <sw@weilnetz.de>
Reviewed-by: Pierrick Bouvier <pierrick.bouvier@linaro.org>
Reviewed-by: Michael Tokarev <mjt@tls.msk.ru>
Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>
Commit c0ddcb2cbc introduced the test which uses cache=direct
mode, without checking if the scratch filesystem supports O_DIRECT.
A subsequent commit, afeb002e0a, tried to fix that issue, but
instead of checking for o_direct, it checked for
`_supported_cache_modes none directsync`, which is not what the
original mirror-sparse test uses. Fix both by actually checking
for o_direct.
Fixes: c0ddcb2cbc "tests: Add iotest mirror-sparse for recent patches"
Fixes: afeb002e0a "tests/qemu-iotests/tests/mirror-sparse: skip if O_DIRECT is not supported"
Reviewed-by: Stefan Hajnoczi <stefanha@redhat.com>
Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>
Replace -1 comparisons for wint_t with WEOF to fix infinite loop caused by a
65535 == -1 comparison.
Resolves: https://gitlab.com/qemu-project/qemu/-/issues/2905
Signed-off-by: William Hu <purplearmadillo77@proton.me>
Reviewed-by: Philippe Mathieu-Daudé <philmd@linaro.org>
Reviewed-by: Marc-André Lureau <marcandre.lureau@redhat.com>
[ Marc-André - Add missing similar code change, remove a comment ]
Signed-off-by: Marc-André Lureau <marcandre.lureau@redhat.com>
Message-ID: <tSO5to8--iex6QMThG3Z8ElfnNOUahK_yitw2G2tEVRPoMKV936CBdrpyfbeNpVEpziKqeQ1ShBwPOoDkofgApM8YWwnPKJR_JrPDThV8Bc=@proton.me>
The implementation of this workaround does not currently work, so
remove the option entirely to avoid exposing it to users. The code
will remain (temporarily dormant) to be fixed in the next release
cycle.
Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
Reviewed-by: Fabiano Rosas <farosas@suse.de>
Link: https://lore.kernel.org/qemu-devel/20250805182431.504158-1-berrange@redhat.com
Signed-off-by: Fabiano Rosas <farosas@suse.de>
