Add stfle 197 (processor-activity-instrumentation extension 1) to the
gen16 default model and fence it off for 7.1 and older.
Signed-off-by: Christian Borntraeger <borntraeger@linux.ibm.com>
Reviewed-by: David Hildenbrand <david@redhat.com>
Message-Id: <20220727135120.12784-1-borntraeger@linux.ibm.com>
Acked-by: Cornelia Huck <cohuck@redhat.com>
Signed-off-by: Thomas Huth <thuth@redhat.com>
Commits 01ef8185b8 amd 24b36e9813 updated the way that the maximum
transfer length is calculated for patching block limits VPD page in an
INQUIRY response.
The same updates also need to be made for the case where the host device
does not support the block limits VPD page at all and we emulate the
whole page.
Without this fix, on host block devices a maximum transfer length of
(INT_MAX - sector_size) bytes is advertised to the guest, resulting in
I/O errors when a request that exceeds the host limits is made by the
guest. (Prior to commit 24b36e9813, this code path would use the
max_transfer value from the host instead of INT_MAX, but still miss the
fix from 01ef8185b8 where max_transfer is also capped to max_iov
host pages, so it would be less wrong, but still wrong.)
Cc: qemu-stable@nongnu.org
Buglink: https://bugzilla.redhat.com/show_bug.cgi?id=2096251
Fixes: 01ef8185b8
Fixes: 24b36e9813
Signed-off-by: Kevin Wolf <kwolf@redhat.com>
Message-Id: <20220822125320.48257-1-kwolf@redhat.com>
Reviewed-by: Stefan Hajnoczi <stefanha@redhat.com>
Signed-off-by: Kevin Wolf <kwolf@redhat.com>
virtio level reset should not affect pci express
registers such as PM, error or link.
Fixes: 27ce0f3afc ("hw/virtio: fix Power Management Control Register for PCI Express virtio devices")
Fixes: d584f1b9ca ("hw/virtio: fix Link Control Register for PCI Express virtio devices")
Fixes: c2cabb3422 ("hw/virtio: fix error enabling flags in Device Control register")
Cc: "Marcel Apfelbaum" <marcel@redhat.com>
Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
A placeholder of ~0 is used to indicate variable payload size.
Whilst the checks for output payload correctly took this into
account, those for input payload did not.
This results in failure of the Set LSA command.
Fixes: 464e14ac43 ("hw/cxl/device: Implement basic mailbox (8.2.8.4)")
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Message-Id: <20220817145759.32603-4-Jonathan.Cameron@huawei.com>
Reviewed-by: Michael S. Tsirkin <mst@redhat.com>
Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
There is no checking on the availability of a write callback.
Hence QEMU crashes if a write does occur to one of these regions.
Discovered whilst chasing a Linux kernel bug that incorrectly
wrote into one of these regions.
Fixes: 6364adacdf ("hw/cxl/device: Implement the CAP array (8.2.8.1-2)")
Reported-by: Bobo WL <lmw.bobo@gmail.com>
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Message-Id: <20220817145759.32603-2-Jonathan.Cameron@huawei.com>
Reviewed-by: Michael S. Tsirkin <mst@redhat.com>
Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
Two issues were present in this code:
1) Check on which register to look in was inverted.
2) Both branches use the _LO register.
Whilst here moved to extract32() rather than hand rolling
the field extraction as simpler and hopefully less error prone.
Fixes Coverity CID: 1488873
Reported-by: Peter Maydell <peter.maydell@linaro.org>
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Message-Id: <20220808122051.14822-3-Jonathan.Cameron@huawei.com>
Reviewed-by: Michael S. Tsirkin <mst@redhat.com>
Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
Use g_autofree to free the CXLFixedWindow structure if an
error occurs in configuration before we have added to
the list (via g_steal_pointer())
Fix Coverity CID: 1488872
Reported-by: Peter Maydell <peter.maydell@linaro.org>
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Message-Id: <20220808122051.14822-2-Jonathan.Cameron@huawei.com>
Reviewed-by: Michael S. Tsirkin <mst@redhat.com>
Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
Causes regressions when doing direct kernel boots with OVMF.
At this point in the release cycle the only sensible action
is to just disable this for 7.1 and sort it properly in the
7.2 devel cycle.
Cc: Jason A. Donenfeld <Jason@zx2c4.com>
Cc: Marcel Apfelbaum <marcel.apfelbaum@gmail.com>
Cc: Paolo Bonzini <pbonzini@redhat.com>
Cc: Richard Henderson <richard.henderson@linaro.org>
Cc: Eduardo Habkost <eduardo@habkost.net>
Cc: Peter Maydell <peter.maydell@linaro.org>
Cc: Philippe Mathieu-Daudé <f4bug@amsat.org>
Cc: Laurent Vivier <laurent@vivier.eu>
Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
Message-Id: <20220817083940.3174933-1-kraxel@redhat.com>
Cc: Jason A. Donenfeld <Jason@zx2c4.com>
Cc: Marcel Apfelbaum <marcel.apfelbaum@gmail.com>
Cc: Paolo Bonzini <pbonzini@redhat.com>
Cc: Richard Henderson <richard.henderson@linaro.org>
Cc: Eduardo Habkost <eduardo@habkost.net>
Cc: Peter Maydell <peter.maydell@linaro.org>
Cc: Philippe Mathieu-Daudé <f4bug@amsat.org>
Cc: Laurent Vivier <laurent@vivier.eu>
Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
As reads happen in the callback we were never seeing them. We only
really care about the header so move the tracepoint to when the header
is complete.
Fixes: 6ca6d8ee9d (hw/virtio: add vhost_user_[read|write] trace points)
Signed-off-by: Alex Bennée <alex.bennee@linaro.org>
Acked-by: Jason Wang <jasowang@redhat.com>
Message-Id: <20220728135503.1060062-5-alex.bennee@linaro.org>
Reviewed-by: Michael S. Tsirkin <mst@redhat.com>
Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
The assert() protecting against leakage is a little aggressive and
causes needless crashes if a device is shutdown without having been
configured. In this case no descriptors are lost because none have
been assigned.
Signed-off-by: Alex Bennée <alex.bennee@linaro.org>
Message-Id: <20220728135503.1060062-4-alex.bennee@linaro.org>
Reviewed-by: Michael S. Tsirkin <mst@redhat.com>
Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
I've noticed asserts firing because we query the status of vdev after
a vhost connection is closed down. Rather than faulting on the NULL
indirect just quietly reply false.
Signed-off-by: Alex Bennée <alex.bennee@linaro.org>
Message-Id: <20220728135503.1060062-3-alex.bennee@linaro.org>
Reviewed-by: Michael S. Tsirkin <mst@redhat.com>
Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
As soon as virtio_scsi_data_plane_start() attaches host notifiers the
IOThread may start virtqueue processing. There is a race between
IOThread virtqueue processing and virtio_scsi_data_plane_start() because
it only assigns s->dataplane_started after attaching host notifiers.
When a virtqueue handler function in the IOThread calls
virtio_scsi_defer_to_dataplane() it may see !s->dataplane_started and
attempt to start dataplane even though we're already in the IOThread:
#0 0x00007f67b360857c __pthread_kill_implementation (libc.so.6 + 0xa257c)
#1 0x00007f67b35bbd56 raise (libc.so.6 + 0x55d56)
#2 0x00007f67b358e833 abort (libc.so.6 + 0x28833)
#3 0x00007f67b358e75b __assert_fail_base.cold (libc.so.6 + 0x2875b)
#4 0x00007f67b35b4cd6 __assert_fail (libc.so.6 + 0x4ecd6)
#5 0x000055ca87fd411b memory_region_transaction_commit (qemu-kvm + 0x67511b)
#6 0x000055ca87e17811 virtio_pci_ioeventfd_assign (qemu-kvm + 0x4b8811)
#7 0x000055ca87e14836 virtio_bus_set_host_notifier (qemu-kvm + 0x4b5836)
#8 0x000055ca87f8e14e virtio_scsi_set_host_notifier (qemu-kvm + 0x62f14e)
#9 0x000055ca87f8dd62 virtio_scsi_dataplane_start (qemu-kvm + 0x62ed62)
#10 0x000055ca87e14610 virtio_bus_start_ioeventfd (qemu-kvm + 0x4b5610)
#11 0x000055ca87f8c29a virtio_scsi_handle_ctrl (qemu-kvm + 0x62d29a)
#12 0x000055ca87fa5902 virtio_queue_host_notifier_read (qemu-kvm + 0x646902)
#13 0x000055ca882c099e aio_dispatch_handler (qemu-kvm + 0x96199e)
#14 0x000055ca882c1761 aio_poll (qemu-kvm + 0x962761)
#15 0x000055ca880e1052 iothread_run (qemu-kvm + 0x782052)
#16 0x000055ca882c562a qemu_thread_start (qemu-kvm + 0x96662a)
This patch assigns s->dataplane_started before attaching host notifiers
so that virtqueue handler functions that run in the IOThread before
virtio_scsi_data_plane_start() returns correctly identify that dataplane
does not need to be started. This fix is taken from the virtio-blk
dataplane code and it's worth adding a comment in virtio-blk as well to
explain why it works.
Note that s->dataplane_started does not need the AioContext lock because
it is set before attaching host notifiers and cleared after detaching
host notifiers. In other words, the IOThread always sees the value true
and the main loop thread does not modify it while the IOThread is
active.
Buglink: https://bugzilla.redhat.com/show_bug.cgi?id=2099541
Reported-by: Qing Wang <qinwang@redhat.com>
Signed-off-by: Stefan Hajnoczi <stefanha@redhat.com>
Message-Id: <20220808162134.240405-1-stefanha@redhat.com>
Reviewed-by: Emanuele Giuseppe Esposito <eesposit@redhat.com>
Reviewed-by: Michael S. Tsirkin <mst@redhat.com>
Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
The loop condition in xhci_ring_chain_length() is under control of
the guest, and additionally the code does not check for failed DMA
transfers (e.g. if reaching the end of the RAM), so the loop there
could run for a very long time or even forever. Fix it by checking
the return value of dma_memory_read() and by introducing a maximum
loop length.
Resolves: https://gitlab.com/qemu-project/qemu/-/issues/646
Message-Id: <20220804131300.96368-1-thuth@redhat.com>
Reviewed-by: Mauro Matteo Cascella <mcascell@redhat.com>
Acked-by: Gerd Hoffmann <kraxel@redhat.com>
Signed-off-by: Thomas Huth <thuth@redhat.com>
With the introduction of the new TCG GICv4, build_madt() is badly broken
as we do not present any GIC Redistributor structure in MADT for GICv4
guests, so that they have no idea about where the Redistributor
register frames are. This fixes a Linux guest crash at boot time with
ACPI enabled and '-machine gic-version=4'.
While at it, let's convert the remaining hard coded gic_version into
enumeration VIRT_GIC_VERSION_2 for consistency.
Signed-off-by: Zenghui Yu <yuzenghui@huawei.com>
Message-id: 20220812022018.1069-1-yuzenghui@huawei.com
Reviewed-by: Peter Maydell <peter.maydell@linaro.org>
Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
In rocker_port_phys_link_status() and rocker_port_phys_enable_read()
we construct a 64-bit value with one bit per front-panel port.
However we accidentally do the shift as 32-bit arithmetic, which
means that if there are more than 31 front-panel ports this is
undefined behaviour.
Fix the problem by ensuring we use 64-bit arithmetic for the whole
calculation. (We won't ever shift off the 64-bit value because
ROCKER_FP_PORTS_MAX is 62.)
Resolves: Coverity CID 1487121, 1487160
Reviewed-by: Richard Henderson <richard.henderson@linaro.org>
Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
Signed-off-by: Jason Wang <jasowang@redhat.com>
In real hardware, the APB and AHB PNP data tables can be accessed
with byte and halfword reads as well as word reads. Our
implementation currently only handles word reads. Add support for
the 8 and 16 bit accesses. Note that we only need to handle aligned
accesses -- unaligned accesses should continue to trap, as happens on
hardware.
Resolves: https://gitlab.com/qemu-project/qemu/-/issues/1132
Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
Reviewed-by: Frederic Konrad <fkonrad@amd.com>
Message-Id: <20220802131925.3380923-1-peter.maydell@linaro.org>
Tested-by: Tomasz Martyniak <gitlab.com/tom4r>
Signed-off-by: Philippe Mathieu-Daudé <f4bug@amsat.org>
QEMU crashes trying to save VMSTATE when only MIPS target are compiled in
$ qemu-system-mips -monitor stdio
(qemu) migrate "exec:gzip -c > STATEFILE.gz"
Segmentation fault (core dumped)
It happens due to PIIX4_PM trying to parse hotplug vmstate structures
which are valid only for x86 and not for MIPS (as it requires ACPI
tables support which is not existent for ithe later)
Issue was probably exposed by trying to cleanup/compile out unused
ACPI bits from MIPS target (but forgetting about migration bits).
Disable compiled out features using compat properties as the least
risky way to deal with issue.
Signed-off-by: Igor Mammedov <imammedo@redhat.com>
Resolves: https://gitlab.com/qemu-project/qemu/-/issues/995
Reviewed-by: Ani Sinha <ani@anisinha.ca>
Acked-by: Michael S. Tsirkin <mst@redhat.com>
Message-Id: <20220728115034.1327988-1-imammedo@redhat.com>
Signed-off-by: Philippe Mathieu-Daudé <f4bug@amsat.org>
In xlnx_dp_aux_set_command, when the command leads to the default
branch, xlxn-dp will abort and then crash.
This patch removes this abort and drops this operation.
Fixes: 58ac482 ("introduce xlnx-dp")
Resolves: https://gitlab.com/qemu-project/qemu/-/issues/411
Reported-by: Qiang Liu <cyruscyliu@gmail.com>
Tested-by: Qiang Liu <cyruscyliu@gmail.com>
Suggested-by: Thomas Huth <thuth@redhat.com>
Signed-off-by: Qiang Liu <cyruscyliu@gmail.com>
Reviewed-by: Thomas Huth <thuth@redhat.com>
Reviewed-by: Frederic Konrad <fkonrad@amd.com>
Message-Id: <20220808080116.2184881-1-cyruscyliu@gmail.com>
Signed-off-by: Laurent Vivier <laurent@vivier.eu>
Fix a compiler warning on openbsd:
../src/hw/loongarch/acpi-build.c:416:12: warning: variable 'aml_len'
set but not used [-Wunused-but-set-variable]
size_t aml_len = 0;
^
Reported-by: Peter Maydell <peter.maydell@linaro.org>
Signed-off-by: Song Gao <gaosong@loongson.cn>
Reviewed-by: Richard Henderson <richard.henderson@linaro.org>
Message-Id: <20220721040046.3985609-1-gaosong@loongson.cn>
[rth: Removing aml_len in turn makes fadt set but not used.]
Signed-off-by: Richard Henderson <richard.henderson@linaro.org>
We're not storing all GPIO lines we're retrieving with
qdev_get_gpio_in() in mal_irqs[]. We're storing just the last one in the
first index:
for (i = 0; i < ARRAY_SIZE(mal_irqs); i++) {
mal_irqs[0] = qdev_get_gpio_in(uic[2], 3 + i);
}
ppc4xx_mal_init(env, 4, 16, mal_irqs);
mal_irqs is used in ppc4xx_mal_init() to assign the IRQs to MAL:
for (i = 0; i < 4; i++) {
mal->irqs[i] = irqs[i];
}
Since only irqs[0] has been initialized, mal->irqs[1,2,3] are being
zeroed.
This doesn´t seem to trigger any apparent issues at this moment, but
Cedric's QOMification of the MAL device [1] is executing a
sysbus_connect_irq() that will fail if we do not store all GPIO lines
properly.
[1] https://lists.gnu.org/archive/html/qemu-devel/2022-08/msg00497.html
Cc: Peter Maydell <peter.maydell@linaro.org>
Cc: BALATON Zoltan <balaton@eik.bme.hu>
Fixes: 706e944206 ("hw/ppc/sam460ex: Drop use of ppcuic_init()")
Acked-by: BALATON Zoltan <balaton@eik.bme.hu>
Reviewed-by: Cédric Le Goater <clg@kaod.org>
Message-Id: <20220803233204.2724202-1-danielhb413@gmail.com>
Signed-off-by: Daniel Henrique Barboza <danielhb413@gmail.com>
For small disk images (<4 GiB), QEMU and SeaBIOS default to the
LARGE/ECHS disk translation method, but it is not uncommon for other
BIOS software to use LBA in these cases as well. Some operating
system boot loaders (e.g., NT 4) do not handle LARGE translations
outside of fixed configurations. See, e.g., Q154052:
"When starting an x86 based computer, Ntdetect.com retrieves and
stores Interrupt 13 information. . . If the disk controller is using a
32 sector/64 head translation scheme, this boundary will be 1 GB. If
the controller uses 63 sector/255 head translation [AUTHOR: i.e.,
LBA], the limit will be 4 GB."
To accommodate these situations, hd_geometry_guess() now follows the
disk translation specified by the user even when the ATA disk geometry
is guessed.
hd_geometry_guess():
* Only set the disk translation when translation is AUTO.
* Show the soon-to-be active translation (*ptrans) in the trace rather
than what was guessed.
Resolves: https://gitlab.com/qemu-project/qemu/-/issues/56
Buglink: https://bugs.launchpad.net/qemu/+bug/1745312
Signed-off-by: Lev Kujawski <lkujaw@member.fsf.org>
Message-Id: <20220707204045.999544-1-lkujaw@member.fsf.org>
Signed-off-by: Kevin Wolf <kwolf@redhat.com>
* Fix ownership of RAM regions on the fby35 machine
-----BEGIN PGP SIGNATURE-----
iQIzBAABCAAdFiEEoPZlSPBIlev+awtgUaNDx8/77KEFAmLn1N8ACgkQUaNDx8/7
7KHaVA//eh5wIZKeg1Qit8dhVoPXcO7b97KFpBreyCkfdREJpoLjoFe4y+rnKhnL
tJm6qx1YG5s0UN/ODcy4TyKV9CkpcjsRZ+BHuZ+jjiz3WzuarZUTbZx1jVSJP6z0
xcXc3CucKe/yyidGV1gKGiWetuXv2F6nYHzfvJ4auei6Rga8rwmiN7Rqf3Qfh6Lw
Islj/9axfLxGzuMV85uuRZdRrrlmTOjDgnF4mxwVXRrxjtLIaAbzKT6mc1p1FUry
cuE7bDjbZoT7ftBn5y4gQXV38M3XcWzB1KvzMslldkccU7cTbJg8620KSNiscOkJ
03xEJiBJoAzy/X1PUmEODNYUV8a19xcsXEyqaRQiyYtO1XMBDcNkSaiaFacOnhFT
UxabJf3qvzf1QwAmgxGUdbR5usNXsr8Yrnpf1lew7Mvr3SwOYVXqb/JPp+j7uoV3
CVvvTFZm+hBQghaHC0wHBX+C3aLsTis4Jppn5loulo6fb9KZiosj2kPRwEIetVkt
ZgkBOLWRWtizdWKM7HImt7F+v/r7ClFlwAIJj8QQV0HTtVZ+gM6MXWj5oczKENJ8
vPkoP6AUoOWzKFEhBU5XtQ9DdwPSP9m6zAZXl4LD17tVPUPpsuSEDaxhH5hAEnIR
39Mgx7hoK0uLHhM02RrNodD/NDmrZCPV3PwZ979z0Q/C8dttRkY=
=hAJg
-----END PGP SIGNATURE-----
Merge tag 'pull-aspeed-20220801' of https://github.com/legoater/qemu into staging
aspeed queue:
* Fix ownership of RAM regions on the fby35 machine
# -----BEGIN PGP SIGNATURE-----
#
# iQIzBAABCAAdFiEEoPZlSPBIlev+awtgUaNDx8/77KEFAmLn1N8ACgkQUaNDx8/7
# 7KHaVA//eh5wIZKeg1Qit8dhVoPXcO7b97KFpBreyCkfdREJpoLjoFe4y+rnKhnL
# tJm6qx1YG5s0UN/ODcy4TyKV9CkpcjsRZ+BHuZ+jjiz3WzuarZUTbZx1jVSJP6z0
# xcXc3CucKe/yyidGV1gKGiWetuXv2F6nYHzfvJ4auei6Rga8rwmiN7Rqf3Qfh6Lw
# Islj/9axfLxGzuMV85uuRZdRrrlmTOjDgnF4mxwVXRrxjtLIaAbzKT6mc1p1FUry
# cuE7bDjbZoT7ftBn5y4gQXV38M3XcWzB1KvzMslldkccU7cTbJg8620KSNiscOkJ
# 03xEJiBJoAzy/X1PUmEODNYUV8a19xcsXEyqaRQiyYtO1XMBDcNkSaiaFacOnhFT
# UxabJf3qvzf1QwAmgxGUdbR5usNXsr8Yrnpf1lew7Mvr3SwOYVXqb/JPp+j7uoV3
# CVvvTFZm+hBQghaHC0wHBX+C3aLsTis4Jppn5loulo6fb9KZiosj2kPRwEIetVkt
# ZgkBOLWRWtizdWKM7HImt7F+v/r7ClFlwAIJj8QQV0HTtVZ+gM6MXWj5oczKENJ8
# vPkoP6AUoOWzKFEhBU5XtQ9DdwPSP9m6zAZXl4LD17tVPUPpsuSEDaxhH5hAEnIR
# 39Mgx7hoK0uLHhM02RrNodD/NDmrZCPV3PwZ979z0Q/C8dttRkY=
# =hAJg
# -----END PGP SIGNATURE-----
# gpg: Signature made Mon 01 Aug 2022 06:27:59 AM PDT
# gpg: using RSA key A0F66548F04895EBFE6B0B6051A343C7CFFBECA1
# gpg: Good signature from "Cédric Le Goater <clg@kaod.org>" [undefined]
# gpg: WARNING: This key is not certified with a trusted signature!
# gpg: There is no indication that the signature belongs to the owner.
# Primary key fingerprint: A0F6 6548 F048 95EB FE6B 0B60 51A3 43C7 CFFB ECA1
* tag 'pull-aspeed-20220801' of https://github.com/legoater/qemu:
aspeed/fby35: Fix owner of the BMC RAM memory region
aspeed: Remove unused fields from AspeedMachineState
Signed-off-by: Richard Henderson <richard.henderson@linaro.org>
- Improve wordings in some files
-----BEGIN PGP SIGNATURE-----
iQJFBAABCAAvFiEEJ7iIR+7gJQEY8+q5LtnXdP5wLbUFAmLn6aYRHHRodXRoQHJl
ZGhhdC5jb20ACgkQLtnXdP5wLbWekg/+NVIT1jp3tcbfPIE6pB0vI/AhqN3i2hUd
zfJ4V3rSe5tg54JpmuuSt542mp4BDM9bPfYcY/DYESWEtW0c9wv80iP/5LFdJF0G
GYtk7Q4pRXvB32kF0v9OxjCEGPUeEqSRrDrsI/Ify5evEIhr55oHPnDjN/US1Bx+
TIuVfmyz8jhSPHsUvZzfVyFxkHre1+BWDxgM3zxoHFIaWEscIPE1KhwRILbKIxWx
MHpL8JLAneGFwljQoUAMCl7GzHkVna59RhqkbBJ+8iTaNGipQj9FhHZBo2CulO0J
SR7scWowYN8Jt2FNMe3tcKM2xQn/2Fg2TEK4sp6q+hCXhJuvFfWFHBiFYTNpagFA
LGgZmPfDr4uZtMEqY4AdEZdL14YZcoM9E/RpW7GhSvMHy73wOj16O8luH1bU0jtG
6X1VvAZlw8/Son1Tbq2CC6WejlMfJFXSzF6Fy6M7SflMPW44vJOs5uKdW405MYjE
Pksbfz1rwoNfK+1qBNQop7SccgDRvPtlLf3lDAU9V/JHWVEITs1KTfyS+46U8jKA
9SVBzKuTpVd+aXvMgvMAmmqnyvUBPHJ9KcFq4vHNbIETsGaQsXu0Q6waBmpcK8YB
KUL/g0EsdfhkpVVgKYZ4Bzj7shG6SKTdwc/lUcOt+wQuDrZZzaC+A2cu/6ReQN6T
BIHtoaxTz8E=
=K6RW
-----END PGP SIGNATURE-----
Merge tag 'pull-request-2022-08-01' of https://gitlab.com/thuth/qemu into staging
- Some fixes for various tests
- Improve wordings in some files
# -----BEGIN PGP SIGNATURE-----
#
# iQJFBAABCAAvFiEEJ7iIR+7gJQEY8+q5LtnXdP5wLbUFAmLn6aYRHHRodXRoQHJl
# ZGhhdC5jb20ACgkQLtnXdP5wLbWekg/+NVIT1jp3tcbfPIE6pB0vI/AhqN3i2hUd
# zfJ4V3rSe5tg54JpmuuSt542mp4BDM9bPfYcY/DYESWEtW0c9wv80iP/5LFdJF0G
# GYtk7Q4pRXvB32kF0v9OxjCEGPUeEqSRrDrsI/Ify5evEIhr55oHPnDjN/US1Bx+
# TIuVfmyz8jhSPHsUvZzfVyFxkHre1+BWDxgM3zxoHFIaWEscIPE1KhwRILbKIxWx
# MHpL8JLAneGFwljQoUAMCl7GzHkVna59RhqkbBJ+8iTaNGipQj9FhHZBo2CulO0J
# SR7scWowYN8Jt2FNMe3tcKM2xQn/2Fg2TEK4sp6q+hCXhJuvFfWFHBiFYTNpagFA
# LGgZmPfDr4uZtMEqY4AdEZdL14YZcoM9E/RpW7GhSvMHy73wOj16O8luH1bU0jtG
# 6X1VvAZlw8/Son1Tbq2CC6WejlMfJFXSzF6Fy6M7SflMPW44vJOs5uKdW405MYjE
# Pksbfz1rwoNfK+1qBNQop7SccgDRvPtlLf3lDAU9V/JHWVEITs1KTfyS+46U8jKA
# 9SVBzKuTpVd+aXvMgvMAmmqnyvUBPHJ9KcFq4vHNbIETsGaQsXu0Q6waBmpcK8YB
# KUL/g0EsdfhkpVVgKYZ4Bzj7shG6SKTdwc/lUcOt+wQuDrZZzaC+A2cu/6ReQN6T
# BIHtoaxTz8E=
# =K6RW
# -----END PGP SIGNATURE-----
# gpg: Signature made Mon 01 Aug 2022 07:56:38 AM PDT
# gpg: using RSA key 27B88847EEE0250118F3EAB92ED9D774FE702DB5
# gpg: issuer "thuth@redhat.com"
# gpg: Good signature from "Thomas Huth <th.huth@gmx.de>" [undefined]
# gpg: aka "Thomas Huth <thuth@redhat.com>" [undefined]
# gpg: aka "Thomas Huth <th.huth@posteo.de>" [unknown]
# gpg: aka "Thomas Huth <huth@tuxfamily.org>" [undefined]
# gpg: WARNING: This key is not certified with a trusted signature!
# gpg: There is no indication that the signature belongs to the owner.
# Primary key fingerprint: 27B8 8847 EEE0 2501 18F3 EAB9 2ED9 D774 FE70 2DB5
* tag 'pull-request-2022-08-01' of https://gitlab.com/thuth/qemu:
tests/qtest/migration-test: Run the dirty ring tests only with the x86 target
trivial: Fix duplicated words
misc: fix commonly doubled up words
tests/unit/test-qga: Replace the word 'blacklist' in the guest agent unit test
migration-test: Allow test to run without uffd
migration-test: Use migrate_ensure_converge() for auto-converge
tests/tcg/linux-test: Fix random hangs in test_socket
Signed-off-by: Richard Henderson <richard.henderson@linaro.org>
A MachineState object is used as a owner of the RAM region and this
asserts in memory_region_init_ram() when QEMU is built with
CONFIG_QOM_CAST_DEBUG :
/* This will assert if owner is neither NULL nor a DeviceState.
* We only want the owner here for the purposes of defining a
* unique name for migration. TODO: Ideally we should implement
* a naming scheme for Objects which are not DeviceStates, in
* which case we can relax this restriction.
*/
owner_dev = DEVICE(owner);
Use the BMC and BIC objects as the owners of their memory regions.
Cc: Peter Delevoryas <peter@pjd.dev>
Fixes: 778e14cc5c ("aspeed: Add AST2600 (BMC) to fby35")
Reviewed-by: Peter Delevoryas <peter@pjd.dev>
Message-Id: <20220727102714.803041-3-clg@kaod.org>
Signed-off-by: Cédric Le Goater <clg@kaod.org>
Fixes: 346160cbf2 ("aspeed: Set the dram container at the SoC level")
Message-Id: <20220727102714.803041-2-clg@kaod.org>
Signed-off-by: Cédric Le Goater <clg@kaod.org>
The existing code assumes that the block size can be generated from p[1] << 8
in multiple places which ignores the top and bottom 8 bits. If the block size
is allowed to be set to an arbitrary value then this causes a mismatch
between the value written by the guest in the block descriptor and the value
subsequently read back using READ CAPACITY causing the guest to generate
requests that can crash QEMU.
For now restrict block size changes to bits 8-15 and also ignore requests to
set the block size to 0 which causes the SCSI emulation to crash in at least
one place with a divide by zero error.
Fixes: 356c4c441e ("scsi-disk: allow MODE SELECT block descriptor to set the block size")
Closes: https://gitlab.com/qemu-project/qemu/-/issues/1112
Signed-off-by: Mark Cave-Ayland <mark.cave-ayland@ilande.co.uk>
Message-Id: <20220730122656.253448-3-mark.cave-ayland@ilande.co.uk>
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
In scsi_disk_emulate_write_same() the number of host sectors to transfer is
calculated as (s->qdev.blocksize / BDRV_SECTOR_SIZE) which is then used to
copy data in block size chunks to the iov buffer.
Since the loop copying the data to the iov buffer uses a fixed increment of
s->qdev.blocksize then using a block size that isn't a multiple of
BDRV_SECTOR_SIZE introduces a rounding error in the iov buffer size calculation
such that the iov buffer copy overflows the space allocated.
Update the iov buffer copy for() loop so that it will use the smallest of either
the current block size or the remaining transfer count to prevent the overflow.
Signed-off-by: Mark Cave-Ayland <mark.cave-ayland@ilande.co.uk>
Message-Id: <20220730122656.253448-2-mark.cave-ayland@ilande.co.uk>
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
In one case:
memcpy(sid->inmsg + sid->inlen, buf, len);
if len == 0 then sid->inmsg + sig->inlen can point to one past the inmsg
array if the array is full. We have to allow len == 0 due to some
vagueness in the spec, but we don't have to call memcpy.
Found by Coverity. This is not a problem in practice, but the results
are technically (maybe) undefined. So make Coverity happy.
Reported-by: Peter Maydell <peter.maydell@linaro.org>
Signed-off-by: Corey Minyard <cminyard@mvista.com>
Acked-by: Michael S. Tsirkin <mst@redhat.com>
Reviewed-by: Peter Maydell <peter.maydell@linaro.org>
Do not enable ioeventfd by default. Let the feature mature a bit before
we consider enabling it by default.
Fixes: 2e53b0b450 ("hw/nvme: Use ioeventfd to handle doorbell updates")
Reviewed-by: Keith Busch <kbusch@kernel.org>
Reviewed-by: Jinhao Fan <fanjinhao21s@ict.ac.cn>
Signed-off-by: Klaus Jensen <k.jensen@samsung.com>
Make sure the notifier handler is unregistered in the main loop prior to
cleaning it up.
Fixes: 2e53b0b450 ("hw/nvme: Use ioeventfd to handle doorbell updates")
Reviewed-by: Keith Busch <kbusch@kernel.org>
Reviewed-by: Jinhao Fan <fanjinhao21s@ict.ac.cn>
Signed-off-by: Klaus Jensen <k.jensen@samsung.com>
While it is safe to process the queues when they are empty, skip it if
the event notifier callback was invoked spuriously.
Reviewed-by: Keith Busch <kbusch@kernel.org>
Reviewed-by: Jinhao Fan <fanjinhao21s@ict.ac.cn>
Signed-off-by: Klaus Jensen <k.jensen@samsung.com>
Some files wrongly contain the same word twice in a row.
One of them should be removed or replaced.
Message-Id: <20220722145859.1952732-1-thuth@redhat.com>
Signed-off-by: Thomas Huth <thuth@redhat.com>
Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
Message-Id: <20220707163720.1421716-5-berrange@redhat.com>
Reviewed-by: Peter Maydell <peter.maydell@linaro.org>
Signed-off-by: Thomas Huth <thuth@redhat.com>
Change macro name 'LS7A_XXX' to 'VIRT_XXX', as the loongarch
virt machinue use the GPEX bridge instead of LS7A bridge. So
the macro name should keep consistency.
Signed-off-by: Xiaojuan Yang <yangxiaojuan@loongson.cn>
Message-Id: <20220729073018.27037-3-yangxiaojuan@loongson.cn>
Signed-off-by: Richard Henderson <richard.henderson@linaro.org>
1. Rename 'loongson3.c' to 'virt.c' and change the meson.build file.
2. Rename 'loongson3.rst' to 'virt.rst'.
Signed-off-by: Xiaojuan Yang <yangxiaojuan@loongson.cn>
Message-Id: <20220729073018.27037-2-yangxiaojuan@loongson.cn>
Signed-off-by: Richard Henderson <richard.henderson@linaro.org>
Short queue with 2 Coverity fixes and one fix of the
'wait' insns that is causing hangs if the guest kernel uses
the most up to date wait opcode.
- target/ppc:
- implement new wait variants to fix guest hang when using the new opcode
- ppc440_uc: initialize length passed to cpu_physical_memory_map()
- spapr_nvdimm: check if spapr_drc_index() returns NULL
-----BEGIN PGP SIGNATURE-----
iHUEABYKAB0WIQQX6/+ZI9AYAK8oOBk82cqW3gMxZAUCYuK8VgAKCRA82cqW3gMx
ZOc7AQDPMsFY9NHNqJ3O0MiX4Qoy8IGUreZ9dzZSS3zT1nxtEAD+Lwl0/aGO+dk+
+NiIO80A5Agy/0g8PHie4qR3EqHEnwA=
=Q4eR
-----END PGP SIGNATURE-----
Merge tag 'pull-ppc-20220728' of https://gitlab.com/danielhb/qemu into staging
ppc patch queue for 2022-07-28:
Short queue with 2 Coverity fixes and one fix of the
'wait' insns that is causing hangs if the guest kernel uses
the most up to date wait opcode.
- target/ppc:
- implement new wait variants to fix guest hang when using the new opcode
- ppc440_uc: initialize length passed to cpu_physical_memory_map()
- spapr_nvdimm: check if spapr_drc_index() returns NULL
# -----BEGIN PGP SIGNATURE-----
#
# iHUEABYKAB0WIQQX6/+ZI9AYAK8oOBk82cqW3gMxZAUCYuK8VgAKCRA82cqW3gMx
# ZOc7AQDPMsFY9NHNqJ3O0MiX4Qoy8IGUreZ9dzZSS3zT1nxtEAD+Lwl0/aGO+dk+
# +NiIO80A5Agy/0g8PHie4qR3EqHEnwA=
# =Q4eR
# -----END PGP SIGNATURE-----
# gpg: Signature made Thu 28 Jul 2022 09:41:58 AM PDT
# gpg: using EDDSA key 17EBFF9923D01800AF2838193CD9CA96DE033164
# gpg: Good signature from "Daniel Henrique Barboza <danielhb413@gmail.com>" [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: 17EB FF99 23D0 1800 AF28 3819 3CD9 CA96 DE03 3164
* tag 'pull-ppc-20220728' of https://gitlab.com/danielhb/qemu:
target/ppc: Implement new wait variants
hw/ppc/ppc440_uc: Initialize length passed to cpu_physical_memory_map()
hw/ppc: check if spapr_drc_index() returns NULL in spapr_nvdimm.c
Signed-off-by: Richard Henderson <richard.henderson@linaro.org>
When in CGA modes, QEMU wants to ignore the maximum scan field (bits 0..4) of
the maximum scan length register in the CRTC. It is not clear why this is
needed---for example, Bochs ignores bit 7 instead. The issue is that the
CGA modes are not detected correctly, and in particular mode 6 results in
multi_scan==3 according to how SeaBIOS programs it. The right way to check
for CGA graphics modes is to check whether bit 13 of the address is special
cased by the CRT controller to achieve line interleaving, i.e. whether bit 0
of the CRTC mode control register is clear.
Resolves: https://gitlab.com/qemu-project/qemu/-/issues/1020
Reported-by: Korneliusz Osmenda <korneliuszo@gmail.com>
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
In dcr_write_dma(), there is code that uses cpu_physical_memory_map()
to implement a DMA transfer. That function takes a 'plen' argument,
which points to a hwaddr which is used for both input and output: the
caller must set it to the size of the range it wants to map, and on
return it is updated to the actual length mapped. The dcr_write_dma()
code fails to initialize rlen and wlen, so will end up mapping an
unpredictable amount of memory.
Initialize the length values correctly, and check that we managed to
map the entire range before using the fast-path memmove().
This was spotted by Coverity, which points out that we never
initialized the variables before using them.
Fixes: Coverity CID 1487137, 1487150
Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
Reviewed-by: Richard Henderson <richard.henderson@linaro.org>
Message-Id: <20220726182341.1888115-2-peter.maydell@linaro.org>
Signed-off-by: Daniel Henrique Barboza <danielhb413@gmail.com>
spapr_nvdimm_flush_completion_cb() and flush_worker_cb() are using the
DRC object returned by spapr_drc_index() without checking it for NULL.
In this case we would be dereferencing a NULL pointer when doing
SPAPR_NVDIMM(drc->dev) and PC_DIMM(drc->dev).
This can happen if, during a scm_flush(), the DRC object is wrongly
freed/released (e.g. a bug in another part of the code).
spapr_drc_index() would then return NULL in the callbacks.
Fixes: Coverity CID 1487108, 1487178
Reviewed-by: Greg Kurz <groug@kaod.org>
Message-Id: <20220409200856.283076-2-danielhb413@gmail.com>
Signed-off-by: Daniel Henrique Barboza <danielhb413@gmail.com>
Since commit 40244040a7, multi-socket configuration with plic is
broken as the hartid for second socket is calculated incorrectly.
The hartid stored in addr_config already includes the offset
for the base hartid for that socket. Adding it again would lead
to segfault while creating the plic device for the virt machine.
qdev_connect_gpio_out was also invoked with incorrect number of gpio
lines.
Fixes: 40244040a7 (hw/intc: sifive_plic: Avoid overflowing the addr_config buffer)
Signed-off-by: Atish Patra <atishp@rivosinc.com>
Reviewed-by: Alistair Francis <alistair.francis@wdc.com>
Message-Id: <20220723090335.671105-1-atishp@rivosinc.com>
[ Changes by AF:
- Change the qdev_connect_gpio_out() numbering
]
Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
Several fixes. From now on, regression fixes only.
Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
-----BEGIN PGP SIGNATURE-----
iQFDBAABCAAtFiEEXQn9CHHI+FuUyooNKB8NuNKNVGkFAmLgQr8PHG1zdEByZWRo
YXQuY29tAAoJECgfDbjSjVRpGUUIAKtNhrnKopGm4LlRpx8zN3Jc1Jo0nb648gaM
Oyi+Pl8+hpESUhaWN10XDk38/QuPQfIFeR2ZhfYjFTRlZE+n3X9LVlwL8ejjP8KH
AcWm78Ff/SLA45aMKMmw74pvEDNsoPYTp7TrfeIej5ub8BIXr8+8pqDdIR9WwtWO
PbhLNXkTT2yLEs6jCVT4/dyh7zivSkrY7G/RVmtUaFe3PgY8fdW2z3+Txz7UIMgw
CQoGuAucCO5ToBbs2CbT0V5yxY6G5VO6Qd8g0PzDW4M6GsY/Xr5QCnyJe0jTW0d6
Dcc7UZFAzGNzyQCxHCic9xwTO+ZcJPJlH5TwknunxOb9xwCx4Qs=
=zN41
-----END PGP SIGNATURE-----
Merge tag 'for_upstream' of git://git.kernel.org/pub/scm/virt/kvm/mst/qemu into staging
pc,virtio: fixes
Several fixes. From now on, regression fixes only.
Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
# -----BEGIN PGP SIGNATURE-----
#
# iQFDBAABCAAtFiEEXQn9CHHI+FuUyooNKB8NuNKNVGkFAmLgQr8PHG1zdEByZWRo
# YXQuY29tAAoJECgfDbjSjVRpGUUIAKtNhrnKopGm4LlRpx8zN3Jc1Jo0nb648gaM
# Oyi+Pl8+hpESUhaWN10XDk38/QuPQfIFeR2ZhfYjFTRlZE+n3X9LVlwL8ejjP8KH
# AcWm78Ff/SLA45aMKMmw74pvEDNsoPYTp7TrfeIej5ub8BIXr8+8pqDdIR9WwtWO
# PbhLNXkTT2yLEs6jCVT4/dyh7zivSkrY7G/RVmtUaFe3PgY8fdW2z3+Txz7UIMgw
# CQoGuAucCO5ToBbs2CbT0V5yxY6G5VO6Qd8g0PzDW4M6GsY/Xr5QCnyJe0jTW0d6
# Dcc7UZFAzGNzyQCxHCic9xwTO+ZcJPJlH5TwknunxOb9xwCx4Qs=
# =zN41
# -----END PGP SIGNATURE-----
# gpg: Signature made Tue 26 Jul 2022 12:38:39 PM PDT
# gpg: using RSA key 5D09FD0871C8F85B94CA8A0D281F0DB8D28D5469
# gpg: issuer "mst@redhat.com"
# gpg: Good signature from "Michael S. Tsirkin <mst@kernel.org>" [undefined]
# gpg: aka "Michael S. Tsirkin <mst@redhat.com>" [undefined]
# gpg: WARNING: This key is not certified with a trusted signature!
# gpg: There is no indication that the signature belongs to the owner.
# Primary key fingerprint: 0270 606B 6F3C DF3D 0B17 0970 C350 3912 AFBE 8E67
# Subkey fingerprint: 5D09 FD08 71C8 F85B 94CA 8A0D 281F 0DB8 D28D 5469
* tag 'for_upstream' of git://git.kernel.org/pub/scm/virt/kvm/mst/qemu:
hw/virtio/virtio-iommu: Enforce power-of-two notify for both MAP and UNMAP
i386/pc: restrict AMD only enforcing of 1Tb hole to new machine type
i386/pc: relocate 4g start to 1T where applicable
i386/pc: bounds check phys-bits against max used GPA
i386/pc: factor out device_memory base/size to helper
i386/pc: handle unitialized mr in pc_get_cxl_range_end()
i386/pc: factor out cxl range start to helper
i386/pc: factor out cxl range end to helper
i386/pc: factor out above-4g end to an helper
i386/pc: pass pci_hole64_size to pc_memory_init()
i386/pc: create pci-host qdev prior to pc_memory_init()
hw/i386: add 4g boundary start to X86MachineState
hw/cxl: Fix size of constant in interleave granularity function.
hw/i386/pc: Always place CXL Memory Regions after device_memory
hw/machine: Clear out left over CXL related pointer from move of state handling to machines.
acpi/nvdimm: Define trace events for NVDIMM and substitute nvdimm_debug()
Signed-off-by: Richard Henderson <richard.henderson@linaro.org>
Currently we only enforce power-of-two mappings (required by the QEMU
notifier) for UNMAP requests. A MAP request not aligned on a
power-of-two may be successfully handled by VFIO, and then the
corresponding UNMAP notify will fail because it will attempt to split
that mapping. Ensure MAP and UNMAP notifications are consistent.
Fixes: dde3f08b5c ("virtio-iommu: Handle non power of 2 range invalidations")
Reported-by: Tina Zhang <tina.zhang@intel.com>
Signed-off-by: Jean-Philippe Brucker <jean-philippe@linaro.org>
Message-Id: <20220718135636.338264-1-jean-philippe@linaro.org>
Tested-by: Tina Zhang <tina.zhang@intel.com>
Reviewed-by: Michael S. Tsirkin <mst@redhat.com>
Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
The added enforcing is only relevant in the case of AMD where the
range right before the 1TB is restricted and cannot be DMA mapped
by the kernel consequently leading to IOMMU INVALID_DEVICE_REQUEST
or possibly other kinds of IOMMU events in the AMD IOMMU.
Although, there's a case where it may make sense to disable the
IOVA relocation/validation when migrating from a
non-amd-1tb-aware qemu to one that supports it.
Relocating RAM regions to after the 1Tb hole has consequences for
guest ABI because we are changing the memory mapping, so make
sure that only new machine enforce but not older ones.
Signed-off-by: Joao Martins <joao.m.martins@oracle.com>
Acked-by: Dr. David Alan Gilbert <dgilbert@redhat.com>
Acked-by: Igor Mammedov <imammedo@redhat.com>
Message-Id: <20220719170014.27028-12-joao.m.martins@oracle.com>
Reviewed-by: Michael S. Tsirkin <mst@redhat.com>
Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
It is assumed that the whole GPA space is available to be DMA
addressable, within a given address space limit, except for a
tiny region before the 4G. Since Linux v5.4, VFIO validates
whether the selected GPA is indeed valid i.e. not reserved by
IOMMU on behalf of some specific devices or platform-defined
restrictions, and thus failing the ioctl(VFIO_DMA_MAP) with
-EINVAL.
AMD systems with an IOMMU are examples of such platforms and
particularly may only have these ranges as allowed:
0000000000000000 - 00000000fedfffff (0 .. 3.982G)
00000000fef00000 - 000000fcffffffff (3.983G .. 1011.9G)
0000010000000000 - ffffffffffffffff (1Tb .. 16Pb[*])
We already account for the 4G hole, albeit if the guest is big
enough we will fail to allocate a guest with >1010G due to the
~12G hole at the 1Tb boundary, reserved for HyperTransport (HT).
[*] there is another reserved region unrelated to HT that exists
in the 256T boundary in Fam 17h according to Errata #1286,
documeted also in "Open-Source Register Reference for AMD Family
17h Processors (PUB)"
When creating the region above 4G, take into account that on AMD
platforms the HyperTransport range is reserved and hence it
cannot be used either as GPAs. On those cases rather than
establishing the start of ram-above-4g to be 4G, relocate instead
to 1Tb. See AMD IOMMU spec, section 2.1.2 "IOMMU Logical
Topology", for more information on the underlying restriction of
IOVAs.
After accounting for the 1Tb hole on AMD hosts, mtree should
look like:
0000000000000000-000000007fffffff (prio 0, i/o):
alias ram-below-4g @pc.ram 0000000000000000-000000007fffffff
0000010000000000-000001ff7fffffff (prio 0, i/o):
alias ram-above-4g @pc.ram 0000000080000000-000000ffffffffff
If the relocation is done or the address space covers it, we
also add the the reserved HT e820 range as reserved.
Default phys-bits on Qemu is TCG_PHYS_ADDR_BITS (40) which is enough
to address 1Tb (0xff ffff ffff). On AMD platforms, if a
ram-above-4g relocation is attempted and the CPU wasn't configured
with a big enough phys-bits, an error message will be printed
due to the maxphysaddr vs maxusedaddr check previously added.
Suggested-by: Igor Mammedov <imammedo@redhat.com>
Signed-off-by: Joao Martins <joao.m.martins@oracle.com>
Acked-by: Igor Mammedov <imammedo@redhat.com>
Message-Id: <20220719170014.27028-11-joao.m.martins@oracle.com>
Reviewed-by: Michael S. Tsirkin <mst@redhat.com>
Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
