[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Qemu-commits] [qemu/qemu] a08c78: memory: prevent dma-reentracy issues
|
From: |
Alex Bennée |
|
Subject: |
[Qemu-commits] [qemu/qemu] a08c78: memory: prevent dma-reentracy issues |
|
Date: |
Thu, 21 Sep 2023 09:31:43 -0700 |
Branch: refs/heads/stable-8.0
Home: https://github.com/qemu/qemu
Commit: a08c78dda7e018fbbe33bc7979f7a53f89a488b5
https://github.com/qemu/qemu/commit/a08c78dda7e018fbbe33bc7979f7a53f89a488b5
Author: Alexander Bulekov <alxndr@bu.edu>
Date: 2023-09-10 (Sun, 10 Sep 2023)
Changed paths:
M include/exec/memory.h
M include/hw/qdev-core.h
M softmmu/memory.c
Log Message:
-----------
memory: prevent dma-reentracy issues
Add a flag to the DeviceState, when a device is engaged in PIO/MMIO/DMA.
This flag is set/checked prior to calling a device's MemoryRegion
handlers, and set when device code initiates DMA. The purpose of this
flag is to prevent two types of DMA-based reentrancy issues:
1.) mmio -> dma -> mmio case
2.) bh -> dma write -> mmio case
These issues have led to problems such as stack-exhaustion and
use-after-frees.
Summary of the problem from Peter Maydell:
https://lore.kernel.org/qemu-devel/CAFEAcA_23vc7hE3iaM-JVA6W38LK4hJoWae5KcknhPRD5fPBZA@mail.gmail.com
Resolves: https://gitlab.com/qemu-project/qemu/-/issues/62
Resolves: https://gitlab.com/qemu-project/qemu/-/issues/540
Resolves: https://gitlab.com/qemu-project/qemu/-/issues/541
Resolves: https://gitlab.com/qemu-project/qemu/-/issues/556
Resolves: https://gitlab.com/qemu-project/qemu/-/issues/557
Resolves: https://gitlab.com/qemu-project/qemu/-/issues/827
Resolves: https://gitlab.com/qemu-project/qemu/-/issues/1282
Resolves: CVE-2023-0330
Signed-off-by: Alexander Bulekov <alxndr@bu.edu>
Reviewed-by: Thomas Huth <thuth@redhat.com>
Message-Id: <20230427211013.2994127-2-alxndr@bu.edu>
[thuth: Replace warn_report() with warn_report_once()]
Signed-off-by: Thomas Huth <thuth@redhat.com>
(cherry picked from commit a2e1753b8054344f32cf94f31c6399a58794a380)
Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>
Commit: 932cf49f0620544d1fb37f1d8dd02219a3636ee9
https://github.com/qemu/qemu/commit/932cf49f0620544d1fb37f1d8dd02219a3636ee9
Author: Alexander Bulekov <alxndr@bu.edu>
Date: 2023-09-10 (Sun, 10 Sep 2023)
Changed paths:
M docs/devel/multiple-iothreads.txt
M include/block/aio.h
M include/qemu/main-loop.h
M tests/unit/ptimer-test-stubs.c
M util/async.c
M util/main-loop.c
M util/trace-events
Log Message:
-----------
async: Add an optional reentrancy guard to the BH API
Devices can pass their MemoryReentrancyGuard (from their DeviceState),
when creating new BHes. Then, the async API will toggle the guard
before/after calling the BH call-back. This prevents bh->mmio reentrancy
issues.
Signed-off-by: Alexander Bulekov <alxndr@bu.edu>
Reviewed-by: Darren Kenny <darren.kenny@oracle.com>
Message-Id: <20230427211013.2994127-3-alxndr@bu.edu>
[thuth: Fix "line over 90 characters" checkpatch.pl error]
Signed-off-by: Thomas Huth <thuth@redhat.com>
(cherry picked from commit 9c86c97f12c060bf7484dd931f38634e166a81f0)
Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>
Commit: 6a33d4b3453b46ee3fd432d80374f45919985b00
https://github.com/qemu/qemu/commit/6a33d4b3453b46ee3fd432d80374f45919985b00
Author: Alexander Bulekov <alxndr@bu.edu>
Date: 2023-09-10 (Sun, 10 Sep 2023)
Changed paths:
M util/async.c
Log Message:
-----------
async: avoid use-after-free on re-entrancy guard
A BH callback can free the BH, causing a use-after-free in aio_bh_call.
Fix that by keeping a local copy of the re-entrancy guard pointer.
Buglink: https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=58513
Fixes: 9c86c97f12 ("async: Add an optional reentrancy guard to the BH API")
Signed-off-by: Alexander Bulekov <alxndr@bu.edu>
Message-Id: <20230501141956.3444868-1-alxndr@bu.edu>
Reviewed-by: Thomas Huth <thuth@redhat.com>
Signed-off-by: Thomas Huth <thuth@redhat.com>
(cherry picked from commit 7915bd06f25e1803778081161bf6fa10c42dc7cd)
Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>
Commit: db56206f785909aa830e2a19336bb12abca50e82
https://github.com/qemu/qemu/commit/db56206f785909aa830e2a19336bb12abca50e82
Author: Alexander Bulekov <alxndr@bu.edu>
Date: 2023-09-10 (Sun, 10 Sep 2023)
Changed paths:
M scripts/checkpatch.pl
Log Message:
-----------
checkpatch: add qemu_bh_new/aio_bh_new checks
Advise authors to use the _guarded versions of the APIs, instead.
Signed-off-by: Alexander Bulekov <alxndr@bu.edu>
Reviewed-by: Darren Kenny <darren.kenny@oracle.com>
Message-Id: <20230427211013.2994127-4-alxndr@bu.edu>
Signed-off-by: Thomas Huth <thuth@redhat.com>
(cherry picked from commit ef56ffbdd6b0605dc1e305611287b948c970e236)
Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>
Commit: fd9de51ea3f109d427bced84d80815a97bb7faa0
https://github.com/qemu/qemu/commit/fd9de51ea3f109d427bced84d80815a97bb7faa0
Author: Alexander Bulekov <alxndr@bu.edu>
Date: 2023-09-10 (Sun, 10 Sep 2023)
Changed paths:
M hw/9pfs/xen-9p-backend.c
M hw/block/dataplane/virtio-blk.c
M hw/block/dataplane/xen-block.c
M hw/char/virtio-serial-bus.c
M hw/display/qxl.c
M hw/display/virtio-gpu.c
M hw/ide/ahci.c
M hw/ide/ahci_internal.h
M hw/ide/core.c
M hw/misc/imx_rngc.c
M hw/misc/macio/mac_dbdma.c
M hw/net/virtio-net.c
M hw/nvme/ctrl.c
M hw/scsi/mptsas.c
M hw/scsi/scsi-bus.c
M hw/scsi/vmw_pvscsi.c
M hw/usb/dev-uas.c
M hw/usb/hcd-dwc2.c
M hw/usb/hcd-ehci.c
M hw/usb/hcd-uhci.c
M hw/usb/host-libusb.c
M hw/usb/redirect.c
M hw/usb/xen-usb.c
M hw/virtio/virtio-balloon.c
M hw/virtio/virtio-crypto.c
Log Message:
-----------
hw: replace most qemu_bh_new calls with qemu_bh_new_guarded
This protects devices from bh->mmio reentrancy issues.
Thanks: Thomas Huth <thuth@redhat.com> for diagnosing OS X test failure.
Signed-off-by: Alexander Bulekov <alxndr@bu.edu>
Reviewed-by: Darren Kenny <darren.kenny@oracle.com>
Reviewed-by: Stefan Hajnoczi <stefanha@redhat.com>
Reviewed-by: Michael S. Tsirkin <mst@redhat.com>
Reviewed-by: Paul Durrant <paul@xen.org>
Reviewed-by: Thomas Huth <thuth@redhat.com>
Message-Id: <20230427211013.2994127-5-alxndr@bu.edu>
Signed-off-by: Thomas Huth <thuth@redhat.com>
(cherry picked from commit f63192b0544af5d3e4d5edfd85ab520fcf671377)
Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>
Commit: db43c7db206427ff5f6cbc7116c66d6cc6e81385
https://github.com/qemu/qemu/commit/db43c7db206427ff5f6cbc7116c66d6cc6e81385
Author: Alexander Bulekov <alxndr@bu.edu>
Date: 2023-09-10 (Sun, 10 Sep 2023)
Changed paths:
M hw/scsi/lsi53c895a.c
Log Message:
-----------
lsi53c895a: disable reentrancy detection for script RAM
As the code is designed to use the memory APIs to access the script ram,
disable reentrancy checks for the pseudo-RAM ram_io MemoryRegion.
In the future, ram_io may be converted from an IO to a proper RAM MemoryRegion.
Reported-by: Fiona Ebner <f.ebner@proxmox.com>
Signed-off-by: Alexander Bulekov <alxndr@bu.edu>
Reviewed-by: Thomas Huth <thuth@redhat.com>
Reviewed-by: Darren Kenny <darren.kenny@oracle.com>
Message-Id: <20230427211013.2994127-6-alxndr@bu.edu>
Signed-off-by: Thomas Huth <thuth@redhat.com>
(cherry picked from commit bfd6e7ae6a72b84e2eb9574f56e6ec037f05182c)
Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>
Commit: 0f0fb19d2bae3a5184fdbfcaa5de24f6ce759042
https://github.com/qemu/qemu/commit/0f0fb19d2bae3a5184fdbfcaa5de24f6ce759042
Author: Thomas Huth <thuth@redhat.com>
Date: 2023-09-10 (Sun, 10 Sep 2023)
Changed paths:
M hw/scsi/lsi53c895a.c
Log Message:
-----------
lsi53c895a: disable reentrancy detection for MMIO region, too
While trying to use a SCSI disk on the LSI controller with an
older version of Fedora (25), I'm getting:
qemu: warning: Blocked re-entrant IO on MemoryRegion: lsi-mmio at addr: 0x34
and the SCSI controller is not usable. Seems like we have to
disable the reentrancy checker for the MMIO region, too, to
get this working again.
The problem could be reproduced it like this:
./qemu-system-x86_64 -accel kvm -m 2G -machine q35 \
-device lsi53c810,id=lsi1 -device scsi-hd,drive=d0 \
-drive if=none,id=d0,file=.../somedisk.qcow2 \
-cdrom Fedora-Everything-netinst-i386-25-1.3.iso
Where somedisk.qcow2 is an image that contains already some partitions
and file systems.
In the boot menu of Fedora, go to
"Troubleshooting" -> "Rescue a Fedora system" -> "3) Skip to shell"
Then check "dmesg | grep -i 53c" for failure messages, and try to mount
a partition from somedisk.qcow2.
Message-Id: <20230516090556.553813-1-thuth@redhat.com>
Signed-off-by: Thomas Huth <thuth@redhat.com>
(cherry picked from commit d139fe9ad8a27bcc50b4ead77d2f97d191a0e95e)
Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>
Commit: 83d080e85ae769dddf67118b420ec39bfcc3323f
https://github.com/qemu/qemu/commit/83d080e85ae769dddf67118b420ec39bfcc3323f
Author: Alexander Bulekov <alxndr@bu.edu>
Date: 2023-09-10 (Sun, 10 Sep 2023)
Changed paths:
M hw/misc/bcm2835_property.c
Log Message:
-----------
bcm2835_property: disable reentrancy detection for iomem
As the code is designed for re-entrant calls from bcm2835_property to
bcm2835_mbox and back into bcm2835_property, mark iomem as
reentrancy-safe.
Signed-off-by: Alexander Bulekov <alxndr@bu.edu>
Reviewed-by: Thomas Huth <thuth@redhat.com>
Message-Id: <20230427211013.2994127-7-alxndr@bu.edu>
Signed-off-by: Thomas Huth <thuth@redhat.com>
(cherry picked from commit 985c4a4e547afb9573b6bd6843d20eb2c3d1d1cd)
Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>
Commit: 151649da1b821809d016c03287301ee0f81596c4
https://github.com/qemu/qemu/commit/151649da1b821809d016c03287301ee0f81596c4
Author: Alexander Bulekov <alxndr@bu.edu>
Date: 2023-09-10 (Sun, 10 Sep 2023)
Changed paths:
M hw/pci-host/raven.c
Log Message:
-----------
raven: disable reentrancy detection for iomem
As the code is designed for re-entrant calls from raven_io_ops to
pci-conf, mark raven_io_ops as reentrancy-safe.
Signed-off-by: Alexander Bulekov <alxndr@bu.edu>
Message-Id: <20230427211013.2994127-8-alxndr@bu.edu>
Signed-off-by: Thomas Huth <thuth@redhat.com>
(cherry picked from commit 6dad5a6810d9c60ca320d01276f6133bbcfa1fc7)
Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>
Commit: 305ffdeca8d134e5982e18137fc369eb929b2059
https://github.com/qemu/qemu/commit/305ffdeca8d134e5982e18137fc369eb929b2059
Author: Alexander Bulekov <alxndr@bu.edu>
Date: 2023-09-10 (Sun, 10 Sep 2023)
Changed paths:
M hw/intc/apic.c
Log Message:
-----------
apic: disable reentrancy detection for apic-msi
As the code is designed for re-entrant calls to apic-msi, mark apic-msi
as reentrancy-safe.
Signed-off-by: Alexander Bulekov <alxndr@bu.edu>
Reviewed-by: Darren Kenny <darren.kenny@oracle.com>
Message-Id: <20230427211013.2994127-9-alxndr@bu.edu>
Signed-off-by: Thomas Huth <thuth@redhat.com>
(cherry picked from commit 50795ee051a342c681a9b45671c552fbd6274db8)
Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>
Commit: 48c04e42f033bf2e717052d99192fada589d62b3
https://github.com/qemu/qemu/commit/48c04e42f033bf2e717052d99192fada589d62b3
Author: Alexander Bulekov <alxndr@bu.edu>
Date: 2023-09-10 (Sun, 10 Sep 2023)
Changed paths:
M hw/intc/loongarch_ipi.c
Log Message:
-----------
loongarch: mark loongarch_ipi_iocsr re-entrnacy safe
loongarch_ipi_iocsr MRs rely on re-entrant IO through the ipi_send
function. As such, mark these MRs re-entrancy-safe.
Fixes: a2e1753b80 ("memory: prevent dma-reentracy issues")
Signed-off-by: Alexander Bulekov <alxndr@bu.edu>
Reviewed-by: Song Gao <gaosong@loongson.cn>
Message-Id: <20230506112145.3563708-1-alxndr@bu.edu>
Signed-off-by: Song Gao <gaosong@loongson.cn>
(cherry picked from commit 6d0589e0e6c64b888864a2bf980537be20389264)
Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>
Commit: e7f12ce43d9fc6016c1f12d49bcb5e024663d7ad
https://github.com/qemu/qemu/commit/e7f12ce43d9fc6016c1f12d49bcb5e024663d7ad
Author: Alexander Bulekov <alxndr@bu.edu>
Date: 2023-09-10 (Sun, 10 Sep 2023)
Changed paths:
M hw/ppc/pnv_lpc.c
Log Message:
-----------
pnv_lpc: disable reentrancy detection for lpc-hc
As lpc-hc is designed for re-entrant calls from xscom, mark it
re-entrancy safe.
Reported-by: Thomas Huth <thuth@redhat.com>
Signed-off-by: Alexander Bulekov <alxndr@bu.edu>
[clg: mark opb_master_regs as re-entrancy safe also ]
Signed-off-by: Cédric Le Goater <clg@kaod.org>
Reviewed-by: Frederic Barrat <fbarrat@linux.ibm.com>
Tested-by: Thomas Huth <thuth@redhat.com>
Message-Id: <20230526073850.2772197-1-clg@kaod.org>
Signed-off-by: Daniel Henrique Barboza <danielhb413@gmail.com>
(cherry picked from commit 76f9ebffcd41b62ae9ec26a1c25676f2ae1d9cc3)
Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>
Commit: cfff72b21ebd8bb893181bb1107848cf8903ebaa
https://github.com/qemu/qemu/commit/cfff72b21ebd8bb893181bb1107848cf8903ebaa
Author: Zhao Liu <zhao1.liu@intel.com>
Date: 2023-09-10 (Sun, 10 Sep 2023)
Changed paths:
M hw/core/machine-smp.c
M include/hw/boards.h
Log Message:
-----------
machine: Add helpers to get cores/threads per socket
The number of cores/threads per socket are needed for smbios, and are
also useful for other modules.
Provide the helpers to wrap the calculation of cores/threads per socket
so that we can avoid calculation errors caused by other modules miss
topology changes.
Suggested-by: Igor Mammedov <imammedo@redhat.com>
Signed-off-by: Zhao Liu <zhao1.liu@intel.com>
Message-Id: <20230628135437.1145805-2-zhao1.liu@linux.intel.com>
Reviewed-by: Michael S. Tsirkin <mst@redhat.com>
Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
(cherry picked from commit a1d027be95bc375238e5b9292c6aa661a8ddef4c)
Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>
Commit: c107dab4940d19760560ded7651550de9441db28
https://github.com/qemu/qemu/commit/c107dab4940d19760560ded7651550de9441db28
Author: Zhao Liu <zhao1.liu@intel.com>
Date: 2023-09-10 (Sun, 10 Sep 2023)
Changed paths:
M hw/smbios/smbios.c
Log Message:
-----------
hw/smbios: Fix smbios_smp_sockets caculation
smp.sockets is the number of sockets which is configured by "-smp" (
otherwise, the default is 1). Trying to recalculate it here with another
rules leads to errors, such as:
1. 003f230e37d7 ("machine: Tweak the order of topology members in struct
CpuTopology") changes the meaning of smp.cores but doesn't fix
original smp.cores uses.
With the introduction of cluster, now smp.cores means the number of
cores in one cluster. So smp.cores * smp.threads just means the
threads in a cluster not in a socket.
2. On the other hand, we shouldn't use smp.cpus here because it
indicates the initial number of online CPUs at the boot time, and is
not mathematically related to smp.sockets.
So stop reinventing the another wheel and use the topo values that
has been calculated.
Fixes: 003f230e37d7 ("machine: Tweak the order of topology members in struct
CpuTopology")
Signed-off-by: Zhao Liu <zhao1.liu@intel.com>
Message-Id: <20230628135437.1145805-3-zhao1.liu@linux.intel.com>
Reviewed-by: Michael S. Tsirkin <mst@redhat.com>
Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
(cherry picked from commit d79a284a44bb7d88b233fb6bb12ea3723f43469d)
Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>
Commit: ce2e3879a4a55317febdc42a0bc22b4a89e80824
https://github.com/qemu/qemu/commit/ce2e3879a4a55317febdc42a0bc22b4a89e80824
Author: Zhao Liu <zhao1.liu@intel.com>
Date: 2023-09-10 (Sun, 10 Sep 2023)
Changed paths:
M hw/smbios/smbios.c
Log Message:
-----------
hw/smbios: Fix thread count in type4
>From SMBIOS 3.0 specification, thread count field means:
Thread Count is the total number of threads detected by the BIOS for
this processor socket. It is a processor-wide count, not a
thread-per-core count. [1]
So here we should use threads per socket other than threads per core.
[1] SMBIOS 3.0.0, section 7.5.8, Processor Information - Thread Count
Fixes: c97294ec1b9e ("SMBIOS: Build aggregate smbios tables and entry point")
Signed-off-by: Zhao Liu <zhao1.liu@intel.com>
Message-Id: <20230628135437.1145805-4-zhao1.liu@linux.intel.com>
Reviewed-by: Michael S. Tsirkin <mst@redhat.com>
Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
(cherry picked from commit 7298fd7de5551c4501f54381228458e3c21cab4b)
Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>
Commit: abb4828d5d5cd0fba82e958779a7c14d3b44e2df
https://github.com/qemu/qemu/commit/abb4828d5d5cd0fba82e958779a7c14d3b44e2df
Author: Zhao Liu <zhao1.liu@intel.com>
Date: 2023-09-10 (Sun, 10 Sep 2023)
Changed paths:
M hw/smbios/smbios.c
Log Message:
-----------
hw/smbios: Fix core count in type4
>From SMBIOS 3.0 specification, core count field means:
Core Count is the number of cores detected by the BIOS for this
processor socket. [1]
Before 003f230e37d7 ("machine: Tweak the order of topology members in
struct CpuTopology"), MachineState.smp.cores means "the number of cores
in one package", and it's correct to use smp.cores for core count.
But 003f230e37d7 changes the smp.cores' meaning to "the number of cores
in one die" and doesn't change the original smp.cores' use in smbios as
well, which makes core count in type4 go wrong.
Fix this issue with the correct "cores per socket" caculation.
[1] SMBIOS 3.0.0, section 7.5.6, Processor Information - Core Count
Fixes: 003f230e37d7 ("machine: Tweak the order of topology members in struct
CpuTopology")
Signed-off-by: Zhao Liu <zhao1.liu@intel.com>
Message-Id: <20230628135437.1145805-5-zhao1.liu@linux.intel.com>
Reviewed-by: Michael S. Tsirkin <mst@redhat.com>
Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
(cherry picked from commit 196ea60a734c346d7d75f1d89aa37703d4d854e7)
Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>
Commit: 07b7ec0af04711f62c7c274d1440d10efb936ede
https://github.com/qemu/qemu/commit/07b7ec0af04711f62c7c274d1440d10efb936ede
Author: BALATON Zoltan <balaton@eik.bme.hu>
Date: 2023-09-10 (Sun, 10 Sep 2023)
Changed paths:
M hw/i2c/bitbang_i2c.c
M hw/i2c/trace-events
Log Message:
-----------
hw/i2c: Fix bitbang_i2c_data trace event
The clock and data values were logged swapped. Correct the trace event
text to match what is logged. Also fix a typo in a comment nearby.
Signed-off-by: BALATON Zoltan <balaton@eik.bme.hu>
Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>
(cherry picked from commit 8ada214a902225c90583b644cabd85bc89bf188c)
Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>
Commit: a11a2007a50d6d2b8e57605fc2ec40b9f962df13
https://github.com/qemu/qemu/commit/a11a2007a50d6d2b8e57605fc2ec40b9f962df13
Author: Dongli Zhang <dongli.zhang@oracle.com>
Date: 2023-09-10 (Sun, 10 Sep 2023)
Changed paths:
M dump/dump.c
Log Message:
-----------
dump: kdump-zlib data pages not dumped with pvtime/aarch64
The kdump-zlib data pages are not dumped from aarch64 host when the
'pvtime' is involved, that is, when the block->target_end is not aligned to
page_size. In the below example, it is expected to dump two blocks.
(qemu) info mtree -f
... ...
00000000090a0000-00000000090a0fff (prio 0, ram): pvtime KVM
... ...
0000000040000000-00000001bfffffff (prio 0, ram): mach-virt.ram KVM
... ...
However, there is an issue with get_next_page() so that the pages for
"mach-virt.ram" will not be dumped.
At line 1296, although we have reached at the end of the 'pvtime' block,
since it is not aligned to the page_size (e.g., 0x10000), it will not break
at line 1298.
1255 static bool get_next_page(GuestPhysBlock **blockptr, uint64_t *pfnptr,
1256 uint8_t **bufptr, DumpState *s)
... ...
1294 memcpy(buf + addr % page_size, hbuf, n);
1295 addr += n;
1296 if (addr % page_size == 0) {
1297 /* we filled up the page */
1298 break;
1299 }
As a result, get_next_page() will continue to the next
block ("mach-virt.ram"). Finally, when get_next_page() returns to the
caller:
- 'pfnptr' is referring to the 'pvtime'
- but 'blockptr' is referring to the "mach-virt.ram"
When get_next_page() is called the next time, "*pfnptr += 1" still refers
to the prior 'pvtime'. It will exit immediately because it is out of the
range of the current "mach-virt.ram".
The fix is to break when it is time to come to the next block, so that both
'pfnptr' and 'blockptr' refer to the same block.
Fixes: 94d788408d2d ("dump: fix kdump to work over non-aligned blocks")
Cc: Joe Jin <joe.jin@oracle.com>
Signed-off-by: Dongli Zhang <dongli.zhang@oracle.com>
Reviewed-by: Marc-André Lureau <marcandre.lureau@redhat.com>
Message-ID: <20230713055819.30497-1-dongli.zhang@oracle.com>
(cherry picked from commit 8a64609eea8cb2bac015968c4b62da5bce266e22)
Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>
Commit: dd496f92b97a9a2d36f83a91d8adae90ba65465a
https://github.com/qemu/qemu/commit/dd496f92b97a9a2d36f83a91d8adae90ba65465a
Author: Klaus Jensen <k.jensen@samsung.com>
Date: 2023-09-10 (Sun, 10 Sep 2023)
Changed paths:
M hw/nvme/ctrl.c
Log Message:
-----------
hw/nvme: fix oob memory read in fdp events log
As reported by Trend Micro's Zero Day Initiative, an oob memory read
vulnerability exists in nvme_fdp_events(). The host-provided offset is
not verified.
Fix this.
This is only exploitable when Flexible Data Placement mode (fdp=on) is
enabled.
Fixes: CVE-2023-4135
Fixes: 73064edfb864 ("hw/nvme: flexible data placement emulation")
Reported-by: Trend Micro's Zero Day Initiative
Signed-off-by: Klaus Jensen <k.jensen@samsung.com>
(cherry picked from commit ecb1b7b082d3b7dceff0e486a114502fc52c0fdf)
Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>
Commit: cbd3c5db76f0c91ec092692b3ace2727403e4954
https://github.com/qemu/qemu/commit/cbd3c5db76f0c91ec092692b3ace2727403e4954
Author: Klaus Jensen <k.jensen@samsung.com>
Date: 2023-09-10 (Sun, 10 Sep 2023)
Changed paths:
M hw/nvme/ctrl.c
M hw/nvme/nvme.h
M hw/nvme/trace-events
Log Message:
-----------
hw/nvme: fix compliance issue wrt. iosqes/iocqes
As of prior to this patch, the controller checks the value of CC.IOCQES
and CC.IOSQES prior to enabling the controller. As reported by Ben in
GitLab issue #1691, this is not spec compliant. The controller should
only check these values when queues are created.
This patch moves these checks to nvme_create_cq(). We do not need to
check it in nvme_create_sq() since that will error out if the completion
queue is not already created.
Also, since the controller exclusively supports SQEs of size 64 bytes
and CQEs of size 16 bytes, hard code that.
Resolves: https://gitlab.com/qemu-project/qemu/-/issues/1691
Signed-off-by: Klaus Jensen <k.jensen@samsung.com>
(cherry picked from commit 6a33f2e920ec0b489a77200888e3692664077f2d)
Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>
Commit: f47369c3d114ddd2021d9ca2cdde9fe138675bcb
https://github.com/qemu/qemu/commit/f47369c3d114ddd2021d9ca2cdde9fe138675bcb
Author: Ankit Kumar <ankit.kumar@samsung.com>
Date: 2023-09-10 (Sun, 10 Sep 2023)
Changed paths:
M hw/nvme/dif.c
Log Message:
-----------
hw/nvme: fix CRC64 for guard tag
The nvme CRC64 generator expects the caller to pass inverted seed value.
Pass inverted crc value for metadata buffer.
Cc: qemu-stable@nongnu.org
Fixes: 44219b6029fc ("hw/nvme: 64-bit pi support")
Signed-off-by: Ankit Kumar <ankit.kumar@samsung.com>
Signed-off-by: Klaus Jensen <k.jensen@samsung.com>
(cherry picked from commit dbdb13f931d7cf2d3c3ca662e751bb1551e9eab6)
Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>
Commit: 43328764f7a0c4371f0142a8cee6dcdbeecfa633
https://github.com/qemu/qemu/commit/43328764f7a0c4371f0142a8cee6dcdbeecfa633
Author: Klaus Jensen <k.jensen@samsung.com>
Date: 2023-09-10 (Sun, 10 Sep 2023)
Changed paths:
M hw/nvme/ctrl.c
Log Message:
-----------
hw/nvme: fix null pointer access in directive receive
nvme_directive_receive() does not check if an endurance group has been
configured (set) prior to testing if flexible data placement is enabled
or not.
Fix this.
Cc: qemu-stable@nongnu.org
Resolves: https://gitlab.com/qemu-project/qemu/-/issues/1815
Fixes: 73064edfb864 ("hw/nvme: flexible data placement emulation")
Reviewed-by: Jesper Wendel Devantier <j.devantier@samsung.com>
Signed-off-by: Klaus Jensen <k.jensen@samsung.com>
(cherry picked from commit 6c8f8456cb0b239812dee5211881426496da7b98)
Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>
Commit: bb5f9036d5f6914215c75e19048444b2ce06b190
https://github.com/qemu/qemu/commit/bb5f9036d5f6914215c75e19048444b2ce06b190
Author: Klaus Jensen <k.jensen@samsung.com>
Date: 2023-09-10 (Sun, 10 Sep 2023)
Changed paths:
M hw/nvme/ctrl.c
Log Message:
-----------
hw/nvme: fix null pointer access in ruh update
The Reclaim Unit Update operation in I/O Management Receive does not
verify the presence of a configured endurance group prior to accessing
it.
Fix this.
Cc: qemu-stable@nongnu.org
Fixes: 73064edfb864 ("hw/nvme: flexible data placement emulation")
Reviewed-by: Jesper Wendel Devantier <j.devantier@samsung.com>
Signed-off-by: Klaus Jensen <k.jensen@samsung.com>
(cherry picked from commit 3439ba9c5da943d96f7a3c86e0a7eb2ff48de41c)
Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>
Commit: ee638bc5b53cff87768b0b7c6d2c4a4e275994f6
https://github.com/qemu/qemu/commit/ee638bc5b53cff87768b0b7c6d2c4a4e275994f6
Author: Nathan Egge <negge@xiph.org>
Date: 2023-09-10 (Sun, 10 Sep 2023)
Changed paths:
M linux-user/elfload.c
Log Message:
-----------
linux-user/elfload: Set V in ELF_HWCAP for RISC-V
Set V bit for hwcap if misa is set.
Resolves: https://gitlab.com/qemu-project/qemu/-/issues/1793
Signed-off-by: Nathan Egge <negge@xiph.org>
Reviewed-by: Daniel Henrique Barboza <dbarboza@ventanamicro.com>
Tested-by: Daniel Henrique Barboza <dbarboza@ventanamicro.com>
Message-Id: <20230803131424.40744-1-negge@xiph.org>
Signed-off-by: Richard Henderson <richard.henderson@linaro.org>
(cherry picked from commit 4333f0924c2f2ca8efaebaed8c24f55f77d8b013)
Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>
Commit: 43d2db492878f7931457d6d4d9097f9573917c6d
https://github.com/qemu/qemu/commit/43d2db492878f7931457d6d4d9097f9573917c6d
Author: Richard Henderson <richard.henderson@linaro.org>
Date: 2023-09-10 (Sun, 10 Sep 2023)
Changed paths:
M include/exec/user/abitypes.h
Log Message:
-----------
include/exec/user: Set ABI_LLONG_ALIGNMENT to 4 for microblaze
Based on gcc's microblaze.h setting BIGGEST_ALIGNMENT to 32 bits.
Signed-off-by: Richard Henderson <richard.henderson@linaro.org>
(cherry picked from commit e73f27003e777fd9b77d13e71c5268015b8ed2b6)
Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>
Commit: 40cfe12cb6f8b9d3a1172af2e65540773ad17be1
https://github.com/qemu/qemu/commit/40cfe12cb6f8b9d3a1172af2e65540773ad17be1
Author: Richard Henderson <richard.henderson@linaro.org>
Date: 2023-09-10 (Sun, 10 Sep 2023)
Changed paths:
M include/exec/user/abitypes.h
Log Message:
-----------
include/exec/user: Set ABI_LLONG_ALIGNMENT to 4 for nios2
Based on gcc's nios2.h setting BIGGEST_ALIGNMENT to 32 bits.
Signed-off-by: Richard Henderson <richard.henderson@linaro.org>
(cherry picked from commit ea9812d93f9c3e1a308ac33097021c50d581d10e)
Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>
Commit: af0c16fae9532033453f8c208ad1e2e78701de5c
https://github.com/qemu/qemu/commit/af0c16fae9532033453f8c208ad1e2e78701de5c
Author: Luca Bonissi <qemu@bonslack.org>
Date: 2023-09-10 (Sun, 10 Sep 2023)
Changed paths:
M include/exec/user/abitypes.h
Log Message:
-----------
Fixed incorrect LLONG alignment for openrisc and cris
OpenRISC (or1k) has long long alignment to 4 bytes, but currently not
defined in abitypes.h. This lead to incorrect packing of /epoll_event/
structure and eventually infinite loop while waiting for file
descriptor[s] event[s].
Fixed also CRIS alignments (1 byte for all types).
Signed-off-by: Luca Bonissi <qemu@bonslack.org>
Resolves: https://gitlab.com/qemu-project/qemu/-/issues/1770
Reviewed-by: Thomas Huth <thuth@redhat.com>
Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>
(cherry picked from commit 6ee960823da8fd780ae9912c4327b7e85e80d846)
Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>
Commit: b4b3aac5b542557c63bc24049b61c2640ad90dd9
https://github.com/qemu/qemu/commit/b4b3aac5b542557c63bc24049b61c2640ad90dd9
Author: Bernhard Beschow <shentey@gmail.com>
Date: 2023-09-10 (Sun, 10 Sep 2023)
Changed paths:
M hw/sd/sdhci.c
Log Message:
-----------
hw/sd/sdhci: Do not force sdhci_mmio_*_ops onto all SD controllers
Since commit c0a55a0c9da2 "hw/sd/sdhci: Support big endian SD host controller
interfaces" sdhci_common_realize() forces all SD card controllers to use either
sdhci_mmio_le_ops or sdhci_mmio_be_ops, depending on the "endianness" property.
However, there are device models which use different MMIO ops: TYPE_IMX_USDHC
uses usdhc_mmio_ops and TYPE_S3C_SDHCI uses sdhci_s3c_mmio_ops.
Forcing sdhci_mmio_le_ops breaks SD card handling on the "sabrelite" board, for
example. Fix this by defaulting the io_ops to little endian and switch to big
endian in sdhci_common_realize() only if there is a matchig big endian variant
available.
Fixes: c0a55a0c9da2 ("hw/sd/sdhci: Support big endian SD host controller
interfaces")
Signed-off-by: Bernhard Beschow <shentey@gmail.com>
Tested-by: Guenter Roeck <linux@roeck-us.net>
Message-Id: <20230709080950.92489-1-shentey@gmail.com>
(cherry picked from commit 3b830790151ff231531ef2595793e387dd154efb)
Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>
Commit: 179a37924d55e645e660731f0e389d70a277a1c2
https://github.com/qemu/qemu/commit/179a37924d55e645e660731f0e389d70a277a1c2
Author: Ilya Leoshkevich <iii@linux.ibm.com>
Date: 2023-09-10 (Sun, 10 Sep 2023)
Changed paths:
M target/s390x/tcg/vec_string_helper.c
Log Message:
-----------
target/s390x: Fix the "ignored match" case in VSTRS
Currently the emulation of VSTRS recognizes partial matches in presence
of \0 in the haystack, which, according to PoP, is not correct:
If the ZS flag is one and a zero byte was detected
in the second operand, then there can not be a
partial match ...
Add a check for this. While at it, fold a number of explicitly handled
special cases into the generic logic.
Cc: qemu-stable@nongnu.org
Reported-by: Claudio Fontana <cfontana@suse.de>
Closes: https://lists.gnu.org/archive/html/qemu-devel/2023-08/msg00633.html
Fixes: 1d706f314191 ("target/s390x: vxeh2: vector string search")
Signed-off-by: Ilya Leoshkevich <iii@linux.ibm.com>
Message-Id: <20230804233748.218935-3-iii@linux.ibm.com>
Tested-by: Claudio Fontana <cfontana@suse.de>
Acked-by: David Hildenbrand <david@redhat.com>
Signed-off-by: Thomas Huth <thuth@redhat.com>
(cherry picked from commit 791b2b6a930273db694b9ba48bbb406e78715927)
Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>
Commit: 14f78932e02c15e59f3a0894a08159cd00712765
https://github.com/qemu/qemu/commit/14f78932e02c15e59f3a0894a08159cd00712765
Author: Ilya Leoshkevich <iii@linux.ibm.com>
Date: 2023-09-10 (Sun, 10 Sep 2023)
Changed paths:
M target/s390x/tcg/translate_vx.c.inc
Log Message:
-----------
target/s390x: Use a 16-bit immediate in VREP
Unlike most other instructions that contain an immediate element index,
VREP's one is 16-bit, and not 4-bit. The code uses only 8 bits, so
using, e.g., 0x101 does not lead to a specification exception.
Fix by checking all 16 bits.
Cc: qemu-stable@nongnu.org
Fixes: 28d08731b1d8 ("s390x/tcg: Implement VECTOR REPLICATE")
Signed-off-by: Ilya Leoshkevich <iii@linux.ibm.com>
Message-Id: <20230807163459.849766-1-iii@linux.ibm.com>
Reviewed-by: David Hildenbrand <david@redhat.com>
Signed-off-by: Thomas Huth <thuth@redhat.com>
(cherry picked from commit 23e87d419f347b6b5f4da3bf70d222acc24cdb64)
Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>
Commit: 62ac9cbb6fe2d088dd56cd258c61b033f610fe6f
https://github.com/qemu/qemu/commit/62ac9cbb6fe2d088dd56cd258c61b033f610fe6f
Author: Ilya Leoshkevich <iii@linux.ibm.com>
Date: 2023-09-10 (Sun, 10 Sep 2023)
Changed paths:
M target/s390x/tcg/vec_helper.c
Log Message:
-----------
target/s390x: Fix VSTL with a large length
The length is always truncated to 16 bytes. Do not probe more than
that.
Cc: qemu-stable@nongnu.org
Fixes: 0e0a5b49ad58 ("s390x/tcg: Implement VECTOR STORE WITH LENGTH")
Signed-off-by: Ilya Leoshkevich <iii@linux.ibm.com>
Message-Id: <20230804235624.263260-1-iii@linux.ibm.com>
Reviewed-by: David Hildenbrand <david@redhat.com>
Signed-off-by: Thomas Huth <thuth@redhat.com>
(cherry picked from commit 6db3518ba4fcddd71049718f138552999f0d97b4)
Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>
Commit: 96fd3b85081a119353b9ef3f783c2bc8c63758a2
https://github.com/qemu/qemu/commit/96fd3b85081a119353b9ef3f783c2bc8c63758a2
Author: Ilya Leoshkevich <iii@linux.ibm.com>
Date: 2023-09-10 (Sun, 10 Sep 2023)
Changed paths:
M target/s390x/tcg/translate_vx.c.inc
Log Message:
-----------
target/s390x: Check reserved bits of VFMIN/VFMAX's M5
VFMIN and VFMAX should raise a specification exceptions when bits 1-3
of M5 are set.
Cc: qemu-stable@nongnu.org
Fixes: da4807527f3b ("s390x/tcg: Implement VECTOR FP (MAXIMUM|MINIMUM)")
Signed-off-by: Ilya Leoshkevich <iii@linux.ibm.com>
Message-Id: <20230804234621.252522-1-iii@linux.ibm.com>
Reviewed-by: David Hildenbrand <david@redhat.com>
Signed-off-by: Thomas Huth <thuth@redhat.com>
(cherry picked from commit 6a2ea6151835aa4f5fee29382a421c13b0e6619f)
Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>
Commit: f2f8e74ff4eeca352981be4c5fdb03f19e58be7d
https://github.com/qemu/qemu/commit/f2f8e74ff4eeca352981be4c5fdb03f19e58be7d
Author: Thomas Huth <thuth@redhat.com>
Date: 2023-09-10 (Sun, 10 Sep 2023)
Changed paths:
M include/hw/virtio/virtio-gpu-bswap.h
Log Message:
-----------
include/hw/virtio/virtio-gpu: Fix virtio-gpu with blob on big endian hosts
Using "-device virtio-gpu,blob=true" currently does not work on big
endian hosts (like s390x). The guest kernel prints an error message
like:
[drm:virtio_gpu_dequeue_ctrl_func [virtio_gpu]] *ERROR* response 0x1200
(command 0x10c)
and the display stays black. When running QEMU with "-d guest_errors",
it shows an error message like this:
virtio_gpu_create_mapping_iov: nr_entries is too big (83886080 > 16384)
which indicates that this value has not been properly byte-swapped.
And indeed, the virtio_gpu_create_blob_bswap() function (that should
swap the fields in the related structure) fails to swap some of the
entries. After correctly swapping all missing values here, too, the
virtio-gpu device is now also working with blob=true on s390x hosts.
Fixes: e0933d91b1 ("virtio-gpu: Add virtio_gpu_resource_create_blob")
Buglink: https://bugzilla.redhat.com/show_bug.cgi?id=2230469
Message-Id: <20230815122007.928049-1-thuth@redhat.com>
Reviewed-by: Marc-André Lureau <marcandre.lureau@redhat.com>
Signed-off-by: Thomas Huth <thuth@redhat.com>
(cherry picked from commit d194362910138776e8abd6bb3c9fb3693254e95f)
Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>
Commit: aa152711dbed973d7a4ecc725819d3eb280906f1
https://github.com/qemu/qemu/commit/aa152711dbed973d7a4ecc725819d3eb280906f1
Author: Akihiko Odaki <akihiko.odaki@daynix.com>
Date: 2023-09-10 (Sun, 10 Sep 2023)
Changed paths:
M accel/kvm/kvm-all.c
M hw/mips/loongson3_virt.c
M include/sysemu/kvm.h
M target/arm/kvm.c
M target/i386/kvm/kvm.c
M target/mips/kvm.c
M target/mips/kvm_mips.h
M target/ppc/kvm.c
M target/riscv/kvm.c
M target/s390x/kvm/kvm.c
Log Message:
-----------
kvm: Introduce kvm_arch_get_default_type hook
kvm_arch_get_default_type() returns the default KVM type. This hook is
particularly useful to derive a KVM type that is valid for "none"
machine model, which is used by libvirt to probe the availability of
KVM.
For MIPS, the existing mips_kvm_type() is reused. This function ensures
the availability of VZ which is mandatory to use KVM on the current
QEMU.
Cc: qemu-stable@nongnu.org
Signed-off-by: Akihiko Odaki <akihiko.odaki@daynix.com>
Message-id: 20230727073134.134102-2-akihiko.odaki@daynix.com
Reviewed-by: Peter Maydell <peter.maydell@linaro.org>
[PMM: added doc comment for new function]
Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
Reviewed-by: Philippe Mathieu-Daudé <philmd@linaro.org>
(cherry picked from commit 5e0d65909c6f335d578b90491e165440c99adf81)
Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>
Commit: f5cb21416e6fc6a3e2d58f4bb557c929ffe01818
https://github.com/qemu/qemu/commit/f5cb21416e6fc6a3e2d58f4bb557c929ffe01818
Author: Akihiko Odaki <akihiko.odaki@daynix.com>
Date: 2023-09-10 (Sun, 10 Sep 2023)
Changed paths:
M target/arm/kvm.c
Log Message:
-----------
accel/kvm: Specify default IPA size for arm64
Before this change, the default KVM type, which is used for non-virt
machine models, was 0.
The kernel documentation says:
> On arm64, the physical address size for a VM (IPA Size limit) is
> limited to 40bits by default. The limit can be configured if the host
> supports the extension KVM_CAP_ARM_VM_IPA_SIZE. When supported, use
> KVM_VM_TYPE_ARM_IPA_SIZE(IPA_Bits) to set the size in the machine type
> identifier, where IPA_Bits is the maximum width of any physical
> address used by the VM. The IPA_Bits is encoded in bits[7-0] of the
> machine type identifier.
>
> e.g, to configure a guest to use 48bit physical address size::
>
> vm_fd = ioctl(dev_fd, KVM_CREATE_VM, KVM_VM_TYPE_ARM_IPA_SIZE(48));
>
> The requested size (IPA_Bits) must be:
>
> == =========================================================
> 0 Implies default size, 40bits (for backward compatibility)
> N Implies N bits, where N is a positive integer such that,
> 32 <= N <= Host_IPA_Limit
> == =========================================================
> Host_IPA_Limit is the maximum possible value for IPA_Bits on the host
> and is dependent on the CPU capability and the kernel configuration.
> The limit can be retrieved using KVM_CAP_ARM_VM_IPA_SIZE of the
> KVM_CHECK_EXTENSION ioctl() at run-time.
>
> Creation of the VM will fail if the requested IPA size (whether it is
> implicit or explicit) is unsupported on the host.
https://docs.kernel.org/virt/kvm/api.html#kvm-create-vm
So if Host_IPA_Limit < 40, specifying 0 as the type will fail. This
actually confused libvirt, which uses "none" machine model to probe the
KVM availability, on M2 MacBook Air.
Fix this by using Host_IPA_Limit as the default type when
KVM_CAP_ARM_VM_IPA_SIZE is available.
Cc: qemu-stable@nongnu.org
Signed-off-by: Akihiko Odaki <akihiko.odaki@daynix.com>
Message-id: 20230727073134.134102-3-akihiko.odaki@daynix.com
Reviewed-by: Peter Maydell <peter.maydell@linaro.org>
Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
(cherry picked from commit 1ab445af8cd99343f29032b5944023ad7d8edebf)
Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>
Commit: 09640031edd4314b8b2b05235f3da8114b4d5d36
https://github.com/qemu/qemu/commit/09640031edd4314b8b2b05235f3da8114b4d5d36
Author: Richard Henderson <richard.henderson@linaro.org>
Date: 2023-09-10 (Sun, 10 Sep 2023)
Changed paths:
M target/arm/tcg/sme_helper.c
Log Message:
-----------
target/arm: Fix SME ST1Q
A typo, noted in the bug report, resulting in an
incorrect write offset.
Cc: qemu-stable@nongnu.org
Fixes: 7390e0e9ab8 ("target/arm: Implement SME LD1, ST1")
Resolves: https://gitlab.com/qemu-project/qemu/-/issues/1833
Signed-off-by: Richard Henderson <richard.henderson@linaro.org>
Reviewed-by: Philippe Mathieu-Daudé <philmd@linaro.org>
Message-id: 20230818214255.146905-1-richard.henderson@linaro.org
Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
(cherry picked from commit 4b3520fd93cd49cc56dfcab45d90735cc2e35af7)
Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>
Commit: d4c0ac705d720e19d9ec5b9fe1c6c7bb22b6913a
https://github.com/qemu/qemu/commit/d4c0ac705d720e19d9ec5b9fe1c6c7bb22b6913a
Author: Richard Henderson <richard.henderson@linaro.org>
Date: 2023-09-10 (Sun, 10 Sep 2023)
Changed paths:
M target/arm/tcg/translate.c
Log Message:
-----------
target/arm: Fix 64-bit SSRA
Typo applied byte-wise shift instead of double-word shift.
Cc: qemu-stable@nongnu.org
Fixes: 631e565450c ("target/arm: Create gen_gvec_[us]sra")
Resolves: https://gitlab.com/qemu-project/qemu/-/issues/1737
Signed-off-by: Richard Henderson <richard.henderson@linaro.org>
Reviewed-by: Philippe Mathieu-Daudé <philmd@linaro.org>
Message-id: 20230821022025.397682-1-richard.henderson@linaro.org
Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
(cherry picked from commit cd1e4db73646006039f25879af3bff55b2295ff3)
Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>
Commit: 3c934310ffdfef69a085b8061d884d222b1d201b
https://github.com/qemu/qemu/commit/3c934310ffdfef69a085b8061d884d222b1d201b
Author: Philippe Mathieu-Daudé <philmd@linaro.org>
Date: 2023-09-10 (Sun, 10 Sep 2023)
Changed paths:
M docs/about/license.rst
Log Message:
-----------
docs/about/license: Update LICENSE URL
In early 2021 (see commit 2ad784339e "docs: update README to use
GitLab repo URLs") almost all of the code base was converted to
point to GitLab instead of git.qemu.org. During 2023, git.qemu.org
switched from a git mirror to a http redirect to GitLab (see [1]).
Update the LICENSE URL to match its previous content, displaying
the file raw content similarly to gitweb 'blob_plain' format ([2]).
[1]
https://lore.kernel.org/qemu-devel/CABgObfZu3mFc8tM20K-yXdt7F-7eV-uKZN4sKDarSeu7DYoRbA@mail.gmail.com/
[2] https://git-scm.com/docs/gitweb#Documentation/gitweb.txt-blobplain
Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>
Signed-off-by: Philippe Mathieu-Daudé <philmd@linaro.org>
Reviewed-by: Thomas Huth <thuth@redhat.com>
Reviewed-by: Stefan Hajnoczi <stefanha@redhat.com>
Signed-off-by: Stefan Hajnoczi <stefanha@redhat.com>
Message-ID: <20230822125716.55295-1-philmd@linaro.org>
(cherry picked from commit 09a3fffae00b042bed8ad9c351b1a58c505fde37)
Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>
Commit: e8bb4dc55a9a8e52f55c17ee9b50d7436a672881
https://github.com/qemu/qemu/commit/e8bb4dc55a9a8e52f55c17ee9b50d7436a672881
Author: Fabiano Rosas <farosas@suse.de>
Date: 2023-09-10 (Sun, 10 Sep 2023)
Changed paths:
M migration/block.c
Log Message:
-----------
block-migration: Ensure we don't crash during migration cleanup
We can fail the blk_insert_bs() at init_blk_migration(), leaving the
BlkMigDevState without a dirty_bitmap and BlockDriverState. Account
for the possibly missing elements when doing cleanup.
Fix the following crashes:
Thread 1 "qemu-system-x86" received signal SIGSEGV, Segmentation fault.
0x0000555555ec83ef in bdrv_release_dirty_bitmap (bitmap=0x0) at
../block/dirty-bitmap.c:359
359 BlockDriverState *bs = bitmap->bs;
#0 0x0000555555ec83ef in bdrv_release_dirty_bitmap (bitmap=0x0) at
../block/dirty-bitmap.c:359
#1 0x0000555555bba331 in unset_dirty_tracking () at ../migration/block.c:371
#2 0x0000555555bbad98 in block_migration_cleanup_bmds () at
../migration/block.c:681
Thread 1 "qemu-system-x86" received signal SIGSEGV, Segmentation fault.
0x0000555555e971ff in bdrv_op_unblock (bs=0x0, op=BLOCK_OP_TYPE_BACKUP_SOURCE,
reason=0x0) at ../block.c:7073
7073 QLIST_FOREACH_SAFE(blocker, &bs->op_blockers[op], list, next) {
#0 0x0000555555e971ff in bdrv_op_unblock (bs=0x0,
op=BLOCK_OP_TYPE_BACKUP_SOURCE, reason=0x0) at ../block.c:7073
#1 0x0000555555e9734a in bdrv_op_unblock_all (bs=0x0, reason=0x0) at
../block.c:7095
#2 0x0000555555bbae13 in block_migration_cleanup_bmds () at
../migration/block.c:690
Signed-off-by: Fabiano Rosas <farosas@suse.de>
Message-id: 20230731203338.27581-1-farosas@suse.de
Signed-off-by: Stefan Hajnoczi <stefanha@redhat.com>
(cherry picked from commit f187609f27b261702a17f79d20bf252ee0d4f9cd)
Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>
Commit: fcb49ea23c39dd93b8e1d4e0edae67967d28e001
https://github.com/qemu/qemu/commit/fcb49ea23c39dd93b8e1d4e0edae67967d28e001
Author: Maksim Kostin <maksim.kostin@ispras.ru>
Date: 2023-09-10 (Sun, 10 Sep 2023)
Changed paths:
M hw/ppc/e500.c
Log Message:
-----------
hw/ppc/e500: fix broken snapshot replay
ppce500_reset_device_tree is registered for system reset, but after
c4b075318eb1 this function rerandomizes rng-seed via
qemu_guest_getrandom_nofail. And when loading a snapshot, it tries to read
EVENT_RANDOM that doesn't exist, so we have an error:
qemu-system-ppc: Missing random event in the replay log
To fix this, use qemu_register_reset_nosnapshotload instead of
qemu_register_reset.
Reported-by: Vitaly Cheptsov <cheptsov@ispras.ru>
Fixes: c4b075318eb1 ("hw/ppc: pass random seed to fdt ")
Resolves: https://gitlab.com/qemu-project/qemu/-/issues/1634
Signed-off-by: Maksim Kostin <maksim.kostin@ispras.ru>
Reviewed-by: Nicholas Piggin <npiggin@gmail.com>
Signed-off-by: Cédric Le Goater <clg@kaod.org>
(cherry picked from commit 6ec65b69ba17c954414fa23a397fb8a3fcfb4a43)
Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>
Commit: ea25506b5d6439c76a3a6b7b55dd3f861e98eb85
https://github.com/qemu/qemu/commit/ea25506b5d6439c76a3a6b7b55dd3f861e98eb85
Author: Nicholas Piggin <npiggin@gmail.com>
Date: 2023-09-10 (Sun, 10 Sep 2023)
Changed paths:
M hw/ppc/vof.c
Log Message:
-----------
ppc/vof: Fix missed fields in VOF cleanup
Failing to reset the of_instance_last makes ihandle allocation continue
to increase, which causes record-replay replay fail to match the
recorded trace.
Not resetting claimed_base makes VOF eventually run out of memory after
some resets.
Cc: Alexey Kardashevskiy <aik@ozlabs.ru>
Fixes: fc8c745d501 ("spapr: Implement Open Firmware client interface")
Signed-off-by: Nicholas Piggin <npiggin@gmail.com>
Reviewed-by: Alexey Kardashevskiy <aik@ozlabs.ru>
Signed-off-by: Cédric Le Goater <clg@kaod.org>
(cherry picked from commit 7b8589d7ce7e23f26ff53338d575a5cbd7818e28)
Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>
Commit: 956b96f9e25f22a1e66d0dcacfb3621ef8a671b4
https://github.com/qemu/qemu/commit/956b96f9e25f22a1e66d0dcacfb3621ef8a671b4
Author: Richard Henderson <richard.henderson@linaro.org>
Date: 2023-09-10 (Sun, 10 Sep 2023)
Changed paths:
M target/ppc/cpu.c
Log Message:
-----------
target/ppc: Flush inputs to zero with NJ in ppc_store_vscr
Resolves: https://gitlab.com/qemu-project/qemu/-/issues/1779
Signed-off-by: Richard Henderson <richard.henderson@linaro.org>
Reviewed-by: Nicholas Piggin <npiggin@gmail.com>
Signed-off-by: Cédric Le Goater <clg@kaod.org>
(cherry picked from commit af03aeb631eeb81a44d2c0ff5b429cd4b5dc2799)
Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>
Commit: 67894ec9fd512db33a883bd8df01ddac7f9f9780
https://github.com/qemu/qemu/commit/67894ec9fd512db33a883bd8df01ddac7f9f9780
Author: Niklas Cassel <niklas.cassel@wdc.com>
Date: 2023-09-10 (Sun, 10 Sep 2023)
Changed paths:
M hw/ide/core.c
Log Message:
-----------
hw/ide/core: set ERR_STAT in unsupported command completion
Currently, the first time sending an unsupported command
(e.g. READ LOG DMA EXT) will not have ERR_STAT set in the completion.
Sending the unsupported command again, will correctly have ERR_STAT set.
When ide_cmd_permitted() returns false, it calls ide_abort_command().
ide_abort_command() first calls ide_transfer_stop(), which will call
ide_transfer_halt() and ide_cmd_done(), after that ide_abort_command()
sets ERR_STAT in status.
ide_cmd_done() for AHCI will call ahci_write_fis_d2h() which writes the
current status in the FIS, and raises an IRQ. (The status here will not
have ERR_STAT set!).
Thus, we cannot call ide_transfer_stop() before setting ERR_STAT, as
ide_transfer_stop() will result in the FIS being written and an IRQ
being raised.
The reason why it works the second time, is that ERR_STAT will still
be set from the previous command, so when writing the FIS, the
completion will correctly have ERR_STAT set.
Set ERR_STAT before writing the FIS (calling cmd_done), so that we will
raise an error IRQ correctly when receiving an unsupported command.
Signed-off-by: Niklas Cassel <niklas.cassel@wdc.com>
Reviewed-by: Philippe Mathieu-Daudé <philmd@linaro.org>
Message-id: 20230609140844.202795-3-nks@flawful.org
Signed-off-by: John Snow <jsnow@redhat.com>
(cherry picked from commit c3461c6264a7c8ca15b117e91fe5da786924a784)
Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>
Commit: 362a4d8658c9370a071b5e598c158d522a3fa60d
https://github.com/qemu/qemu/commit/362a4d8658c9370a071b5e598c158d522a3fa60d
Author: Niklas Cassel <niklas.cassel@wdc.com>
Date: 2023-09-10 (Sun, 10 Sep 2023)
Changed paths:
M hw/ide/ahci.c
Log Message:
-----------
hw/ide/ahci: write D2H FIS when processing NCQ command
The way that BUSY + PxCI is cleared for NCQ (FPDMA QUEUED) commands is
described in SATA 3.5a Gold:
11.15 FPDMA QUEUED command protocol
DFPDMAQ2: ClearInterfaceBsy
"Transmit Register Device to Host FIS with the BSY bit cleared to zero
and the DRQ bit cleared to zero and Interrupt bit cleared to zero to
mark interface ready for the next command."
PxCI is currently cleared by handle_cmd(), but we don't write the D2H
FIS to the FIS Receive Area that actually caused PxCI to be cleared.
Similar to how ahci_pio_transfer() calls ahci_write_fis_pio() with an
additional parameter to write a PIO Setup FIS without raising an IRQ,
add a parameter to ahci_write_fis_d2h() so that ahci_write_fis_d2h()
also can write the FIS to the FIS Receive Area without raising an IRQ.
Change process_ncq_command() to call ahci_write_fis_d2h() without
raising an IRQ (similar to ahci_pio_transfer()), such that the FIS
Receive Area is in sync with the PxTFD shadow register.
E.g. Linux reads status and error fields from the FIS Receive Area
directly, so it is wise to keep the FIS Receive Area and the PxTFD
shadow register in sync.
Signed-off-by: Niklas Cassel <niklas.cassel@wdc.com>
Message-id: 20230609140844.202795-4-nks@flawful.org
Signed-off-by: John Snow <jsnow@redhat.com>
(cherry picked from commit 2967dc8209dd27b61a6ab7bad78cf7c6ec58ddb4)
Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>
Commit: 7bcd32128b227cee1fb39ff242d486ed9fff7648
https://github.com/qemu/qemu/commit/7bcd32128b227cee1fb39ff242d486ed9fff7648
Author: Niklas Cassel <niklas.cassel@wdc.com>
Date: 2023-09-10 (Sun, 10 Sep 2023)
Changed paths:
M hw/ide/ahci.c
Log Message:
-----------
hw/ide/ahci: simplify and document PxCI handling
The AHCI spec states that:
For NCQ, PxCI is cleared on command queued successfully.
For non-NCQ, PxCI is cleared on command completed successfully.
(A non-NCQ command that completes with error does not clear PxCI.)
The current QEMU implementation either clears PxCI in check_cmd(),
or in ahci_cmd_done().
check_cmd() will clear PxCI for a command if handle_cmd() returns 0.
handle_cmd() will return -1 if BUSY or DRQ is set.
The QEMU implementation for NCQ commands will currently not set BUSY
or DRQ, so they will always have PxCI cleared by handle_cmd().
ahci_cmd_done() will never even get called for NCQ commands.
Non-NCQ commands are executed by ide_bus_exec_cmd().
Non-NCQ commands in QEMU are implemented either in a sync or in an async
way.
For non-NCQ commands implemented in a sync way, the command handler will
return true, and when ide_bus_exec_cmd() sees that a command handler
returns true, it will call ide_cmd_done() (which will call
ahci_cmd_done()). For a command implemented in a sync way,
ahci_cmd_done() will do nothing (since busy_slot is not set). Instead,
after ide_bus_exec_cmd() has finished, check_cmd() will clear PxCI for
these commands.
For non-NCQ commands implemented in an async way (using either aiocb or
pio_aiocb), the command handler will return false, ide_bus_exec_cmd()
will not call ide_cmd_done(), instead it is expected that the async
callback function will call ide_cmd_done() once the async command is
done. handle_cmd() will set busy_slot, if and only if BUSY or DRQ is
set, and this is checked _after_ ide_bus_exec_cmd() has returned.
handle_cmd() will return -1, so check_cmd() will not clear PxCI.
When the async callback calls ide_cmd_done() (which will call
ahci_cmd_done()), it will see that busy_slot is set, and
ahci_cmd_done() will clear PxCI.
This seems racy, since busy_slot is set _after_ ide_bus_exec_cmd() has
returned. The callback might come before busy_slot gets set. And it is
quite confusing that ahci_cmd_done() will be called for all non-NCQ
commands when the command is done, but will only clear PxCI in certain
cases, even though it will always write a D2H FIS and raise an IRQ.
Even worse, in the case where ahci_cmd_done() does not clear PxCI, it
still raises an IRQ. Host software might thus read an old PxCI value,
since PxCI is cleared (by check_cmd()) after the IRQ has been raised.
Try to simplify this by always setting busy_slot for non-NCQ commands,
such that ahci_cmd_done() will always be responsible for clearing PxCI
for non-NCQ commands.
For NCQ commands, clear PxCI when we receive the D2H FIS, but before
raising the IRQ, see AHCI 1.3.1, section 5.3.8, states RegFIS:Entry and
RegFIS:ClearCI.
Signed-off-by: Niklas Cassel <niklas.cassel@wdc.com>
Message-id: 20230609140844.202795-5-nks@flawful.org
Signed-off-by: John Snow <jsnow@redhat.com>
(cherry picked from commit e2a5d9b3d9c3d311618160603cc9bc04fbd98796)
Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>
Commit: 2eaf7775fc05d65c9254530ea0fdbbcf910c92cd
https://github.com/qemu/qemu/commit/2eaf7775fc05d65c9254530ea0fdbbcf910c92cd
Author: Niklas Cassel <niklas.cassel@wdc.com>
Date: 2023-09-10 (Sun, 10 Sep 2023)
Changed paths:
M hw/ide/ahci.c
Log Message:
-----------
hw/ide/ahci: PxSACT and PxCI is cleared when PxCMD.ST is cleared
According to AHCI 1.3.1 definition of PxSACT:
This field is cleared when PxCMD.ST is written from a '1' to a '0' by
software. This field is not cleared by a COMRESET or a software reset.
According to AHCI 1.3.1 definition of PxCI:
This field is also cleared when PxCMD.ST is written from a '1' to a '0'
by software.
Clearing PxCMD.ST is part of the error recovery procedure, see
AHCI 1.3.1, section "6.2 Error Recovery".
If we don't clear PxCI on error recovery, the previous command will
incorrectly still be marked as pending after error recovery.
Signed-off-by: Niklas Cassel <niklas.cassel@wdc.com>
Reviewed-by: Philippe Mathieu-Daudé <philmd@linaro.org>
Message-id: 20230609140844.202795-6-nks@flawful.org
Signed-off-by: John Snow <jsnow@redhat.com>
(cherry picked from commit d73b84d0b664e60fffb66f46e84d0db4a8e1c713)
Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>
Commit: f7cca09987983644d054fc4f4feb8414dcd624c5
https://github.com/qemu/qemu/commit/f7cca09987983644d054fc4f4feb8414dcd624c5
Author: Niklas Cassel <niklas.cassel@wdc.com>
Date: 2023-09-10 (Sun, 10 Sep 2023)
Changed paths:
M hw/ide/ahci.c
M tests/qtest/libqos/ahci.c
M tests/qtest/libqos/ahci.h
Log Message:
-----------
hw/ide/ahci: PxCI should not get cleared when ERR_STAT is set
For NCQ, PxCI is cleared on command queued successfully.
For non-NCQ, PxCI is cleared on command completed successfully.
Successfully means ERR_STAT, BUSY and DRQ are all cleared.
A command that has ERR_STAT set, does not get to clear PxCI.
See AHCI 1.3.1, section 5.3.8, states RegFIS:Entry and RegFIS:ClearCI,
and 5.3.16.5 ERR:FatalTaskfile.
In the case of non-NCQ commands, not clearing PxCI is needed in order
for host software to be able to see which command slot that failed.
Signed-off-by: Niklas Cassel <niklas.cassel@wdc.com>
Message-id: 20230609140844.202795-7-nks@flawful.org
Signed-off-by: John Snow <jsnow@redhat.com>
(cherry picked from commit 1a16ce64fda11bdf50f0c4ab5d9fdde72c1383a2)
Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>
Commit: 9c7e2253eba2e057f11377beb64dd78d12a1e27d
https://github.com/qemu/qemu/commit/9c7e2253eba2e057f11377beb64dd78d12a1e27d
Author: Niklas Cassel <niklas.cassel@wdc.com>
Date: 2023-09-10 (Sun, 10 Sep 2023)
Changed paths:
M hw/ide/ahci.c
Log Message:
-----------
hw/ide/ahci: fix ahci_write_fis_sdb()
When there is an error, we need to raise a TFES error irq, see AHCI 1.3.1,
5.3.13.1 SDB:Entry.
If ERR_STAT is set, we jump to state ERR:FatalTaskfile, which will raise
a TFES IRQ unconditionally, regardless if the I bit is set in the FIS or
not.
Thus, we should never raise a normal IRQ after having sent an error IRQ.
It is valid to signal successfully completed commands as finished in the
same SDB FIS that generates the error IRQ. The important thing is that
commands that did not complete successfully (e.g. commands that were
aborted, do not get the finished bit set).
Before this commit, there was never a TFES IRQ raised on NCQ error.
Signed-off-by: Niklas Cassel <niklas.cassel@wdc.com>
Reviewed-by: Philippe Mathieu-Daudé <philmd@linaro.org>
Message-id: 20230609140844.202795-8-nks@flawful.org
Signed-off-by: John Snow <jsnow@redhat.com>
(cherry picked from commit 7e85cb0db4c693b4e084a00e66fe73a22ed1688a)
Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>
Commit: 4f6c55371743ba9d6512fcf4a88a5b5b8936037e
https://github.com/qemu/qemu/commit/4f6c55371743ba9d6512fcf4a88a5b5b8936037e
Author: Niklas Cassel <niklas.cassel@wdc.com>
Date: 2023-09-10 (Sun, 10 Sep 2023)
Changed paths:
M hw/ide/ahci.c
Log Message:
-----------
hw/ide/ahci: fix broken SError handling
When encountering an NCQ error, you should not write the NCQ tag to the
SError register. This is completely wrong.
The SError register has a clear definition, where each bit represents a
different error, see PxSERR definition in AHCI 1.3.1.
If we write a random value (like the NCQ tag) in SError, e.g. Linux will
read SError, and will trigger arbitrary error handling depending on the
NCQ tag that happened to be executing.
In case of success, ncq_cb() will call ncq_finish().
In case of error, ncq_cb() will call ncq_err() (which will clear
ncq_tfs->used), and then call ncq_finish(), thus using ncq_tfs->used is
sufficient to tell if finished should get set or not.
Signed-off-by: Niklas Cassel <niklas.cassel@wdc.com>
Reviewed-by: Philippe Mathieu-Daudé <philmd@linaro.org>
Message-id: 20230609140844.202795-9-nks@flawful.org
Signed-off-by: John Snow <jsnow@redhat.com>
(cherry picked from commit 9f89423537653de07ca40c18b5ff5b70b104cc93)
Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>
Commit: 4a398e64ba8e9c1eced75217d856668c0d17e62e
https://github.com/qemu/qemu/commit/4a398e64ba8e9c1eced75217d856668c0d17e62e
Author: Hang Yu <francis_yuu@stu.pku.edu.cn>
Date: 2023-09-10 (Sun, 10 Sep 2023)
Changed paths:
M hw/i2c/aspeed_i2c.c
M include/hw/i2c/aspeed_i2c.h
Log Message:
-----------
hw/i2c/aspeed: Fix Tx count and Rx size error in buffer pool mode
Fixed inconsistency between the regisiter bit field definition header file
and the ast2600 datasheet. The reg name is I2CD1C:Pool Buffer Control
Register in old register mode and I2CC0C: Master/Slave Pool Buffer Control
Register in new register mode. They share bit field
[12:8]:Transmit Data Byte Count and bit field
[29:24]:Actual Received Pool Buffer Size according to the datasheet.
According to the ast2600 datasheet,the actual Tx count is
Transmit Data Byte Count plus 1, and the max Rx size is
Receive Pool Buffer Size plus 1, both in Pool Buffer Control Register.
The version before forgot to plus 1, and mistake Rx count for Rx size.
Signed-off-by: Hang Yu <francis_yuu@stu.pku.edu.cn>
Fixes: 3be3d6ccf2ad ("aspeed: i2c: Migrate to registerfields API")
Reviewed-by: Cédric Le Goater <clg@kaod.org>
Signed-off-by: Cédric Le Goater <clg@kaod.org>
(cherry picked from commit 97b8aa5ae9ff197394395eda5062ea3681e09c28)
Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>
Commit: c2ec46c694a176a2ced6d8b62f0ec40569f4a83d
https://github.com/qemu/qemu/commit/c2ec46c694a176a2ced6d8b62f0ec40569f4a83d
Author: Hang Yu <francis_yuu@stu.pku.edu.cn>
Date: 2023-09-10 (Sun, 10 Sep 2023)
Changed paths:
M hw/i2c/aspeed_i2c.c
Log Message:
-----------
hw/i2c/aspeed: Fix TXBUF transmission start position error
According to the ast2600 datasheet and the linux aspeed i2c driver,
the TXBUF transmission start position should be TXBUF[0] instead
of TXBUF[1],so the arg pool_start is useless,and the address is not
included in TXBUF.So even if Tx Count equals zero,there is at least
1 byte data needs to be transmitted,and M_TX_CMD should not be cleared
at this condition.The driver url is:
https://github.com/AspeedTech-BMC/linux/blob/aspeed-master-v5.15/drivers/i2c/busses/i2c-ast2600.c
Signed-off-by: Hang Yu <francis_yuu@stu.pku.edu.cn>
Fixes: 6054fc73e8f4 ("aspeed/i2c: Add support for pool buffer transfers")
Reviewed-by: Cédric Le Goater <clg@kaod.org>
Signed-off-by: Cédric Le Goater <clg@kaod.org>
(cherry picked from commit 961faf3ddbd8ffcdf776bbcf88af0bc97218114a)
Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>
Commit: 45b61f730d953b713dc2bb8b695d6555a5b8adb6
https://github.com/qemu/qemu/commit/45b61f730d953b713dc2bb8b695d6555a5b8adb6
Author: Thomas Huth <thuth@redhat.com>
Date: 2023-09-10 (Sun, 10 Sep 2023)
Changed paths:
M qemu-options.hx
Log Message:
-----------
qemu-options.hx: Rephrase the descriptions of the -hd* and -cdrom options
The current description says that these options will create a device
on the IDE bus, which is only true on x86. So rephrase these sentences
a little bit to speak of "default bus" instead.
Signed-off-by: Thomas Huth <thuth@redhat.com>
Reviewed-by: Alex Bennée <alex.bennee@linaro.org>
Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>
(cherry picked from commit bcd8e243083c878884e52d609deddbe6be17c730)
Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>
Commit: 42edb4723afe4a94a7c8011fa7fe02c3846cdc7e
https://github.com/qemu/qemu/commit/42edb4723afe4a94a7c8011fa7fe02c3846cdc7e
Author: Markus Armbruster <armbru@redhat.com>
Date: 2023-09-10 (Sun, 10 Sep 2023)
Changed paths:
M docs/multi-thread-compression.txt
M docs/rdma.txt
M tests/qemu-iotests/181
M tests/qtest/test-hmp.c
Log Message:
-----------
docs tests: Fix use of migrate_set_parameter
docs/multi-thread-compression.txt uses parameter names with
underscores instead of dashes. Wrong since day one.
docs/rdma.txt, tests/qemu-iotests/181, and tests/qtest/test-hmp.c are
wrong the same way since commit cbde7be900d2 (v6.0.0). Hard to see,
as test-hmp doesn't check whether the commands work, and iotest 181
appears to be unaffected.
Fixes: 263170e679df (docs: Add a doc about multiple thread compression)
Fixes: cbde7be900d2 (migrate: remove QMP/HMP commands for speed, downtime and
cache size)
Signed-off-by: Markus Armbruster <armbru@redhat.com>
Reviewed-by: Thomas Huth <thuth@redhat.com>
Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>
(cherry picked from commit b21a6e31a182a5ae7436a444f840d49aac07c94f)
Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>
Commit: c68b844d3376764240afdb3c55d451e4dac11004
https://github.com/qemu/qemu/commit/c68b844d3376764240afdb3c55d451e4dac11004
Author: Thomas Huth <thuth@redhat.com>
Date: 2023-09-10 (Sun, 10 Sep 2023)
Changed paths:
M hw/net/vmxnet3.c
Log Message:
-----------
hw/net/vmxnet3: Fix guest-triggerable assert()
The assert() that checks for valid MTU sizes can be triggered by
the guest (e.g. with the reproducer code from the bug ticket
https://gitlab.com/qemu-project/qemu/-/issues/517 ). Let's avoid
this problem by simply logging the error and refusing to activate
the device instead.
Fixes: d05dcd94ae ("net: vmxnet3: validate configuration values during
activate")
Signed-off-by: Thomas Huth <thuth@redhat.com>
Cc: qemu-stable@nongnu.org
Reviewed-by: Philippe Mathieu-Daudé <philmd@linaro.org>
Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>
[Mjt: change format specifier from %d to %u for uint32_t argument]
(cherry picked from commit 90a0778421acdf4ca903be64c8ed19378183c944)
Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>
Commit: 5929f5309194e46f40b20aa07797f531663e323f
https://github.com/qemu/qemu/commit/5929f5309194e46f40b20aa07797f531663e323f
Author: Marc-André Lureau <marcandre.lureau@redhat.com>
Date: 2023-09-10 (Sun, 10 Sep 2023)
Changed paths:
M hw/display/qxl.c
Log Message:
-----------
qxl: don't assert() if device isn't yet initialized
If the PCI BAR isn't yet mapped or was unmapped, QXL_IO_SET_MODE will
assert(). Instead, report a guest bug and keep going.
This can be reproduced with:
cat << EOF | ./qemu-system-x86_64 -vga qxl -m 2048 -nodefaults -qtest stdio
outl 0xcf8 0x8000101c
outl 0xcfc 0xc000
outl 0xcf8 0x80001001
outl 0xcfc 0x01000000
outl 0xc006 0x00
EOF
Fixes: https://gitlab.com/qemu-project/qemu/-/issues/1829
Signed-off-by: Marc-André Lureau <marcandre.lureau@redhat.com>
Reviewed-by: Thomas Huth <thuth@redhat.com>
Cc: qemu-stable@nongnu.org
Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>
(cherry picked from commit 95bef686e490bc3afc3f51f5fc6e20bf260b938c)
Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>
Commit: 41af7a9bc41c15460a4dbf4d35879d69c460d02a
https://github.com/qemu/qemu/commit/41af7a9bc41c15460a4dbf4d35879d69c460d02a
Author: Kevin Wolf <kwolf@redhat.com>
Date: 2023-09-11 (Mon, 11 Sep 2023)
Changed paths:
M hw/virtio/virtio.c
Log Message:
-----------
virtio: Drop out of coroutine context in virtio_load()
virtio_load() as a whole should run in coroutine context because it
reads from the migration stream and we don't want this to block.
However, it calls virtio_set_features_nocheck() and devices don't
expect their .set_features callback to run in a coroutine and therefore
call functions that may not be called in coroutine context. To fix this,
drop out of coroutine context for calling virtio_set_features_nocheck().
Without this fix, the following crash was reported:
#0 __pthread_kill_implementation (threadid=<optimized out>,
signo=signo@entry=6, no_tid=no_tid@entry=0) at pthread_kill.c:44
#1 0x00007efc738c05d3 in __pthread_kill_internal (signo=6,
threadid=<optimized out>) at pthread_kill.c:78
#2 0x00007efc73873d26 in __GI_raise (sig=sig@entry=6) at
../sysdeps/posix/raise.c:26
#3 0x00007efc738477f3 in __GI_abort () at abort.c:79
#4 0x00007efc7384771b in __assert_fail_base (fmt=0x7efc739dbcb8 "",
assertion=assertion@entry=0x560aebfbf5cf "!qemu_in_coroutine()",
file=file@entry=0x560aebfcd2d4 "../block/graph-lock.c",
line=line@entry=275, function=function@entry=0x560aebfcd34d "void
bdrv_graph_rdlock_main_loop(void)") at assert.c:92
#5 0x00007efc7386ccc6 in __assert_fail (assertion=0x560aebfbf5cf
"!qemu_in_coroutine()", file=0x560aebfcd2d4 "../block/graph-lock.c", line=275,
function=0x560aebfcd34d "void bdrv_graph_rdlock_main_loop(void)") at
assert.c:101
#6 0x0000560aebcd8dd6 in bdrv_register_buf ()
#7 0x0000560aeb97ed97 in ram_block_added.llvm ()
#8 0x0000560aebb8303f in ram_block_add.llvm ()
#9 0x0000560aebb834fa in qemu_ram_alloc_internal.llvm ()
#10 0x0000560aebb2ac98 in vfio_region_mmap ()
#11 0x0000560aebb3ea0f in vfio_bars_register ()
#12 0x0000560aebb3c628 in vfio_realize ()
#13 0x0000560aeb90f0c2 in pci_qdev_realize ()
#14 0x0000560aebc40305 in device_set_realized ()
#15 0x0000560aebc48e07 in property_set_bool.llvm ()
#16 0x0000560aebc46582 in object_property_set ()
#17 0x0000560aebc4cd58 in object_property_set_qobject ()
#18 0x0000560aebc46ba7 in object_property_set_bool ()
#19 0x0000560aeb98b3ca in qdev_device_add_from_qdict ()
#20 0x0000560aebb1fbaf in virtio_net_set_features ()
#21 0x0000560aebb46b51 in virtio_set_features_nocheck ()
#22 0x0000560aebb47107 in virtio_load ()
#23 0x0000560aeb9ae7ce in vmstate_load_state ()
#24 0x0000560aeb9d2ee9 in qemu_loadvm_state_main ()
#25 0x0000560aeb9d45e1 in qemu_loadvm_state ()
#26 0x0000560aeb9bc32c in process_incoming_migration_co.llvm ()
#27 0x0000560aebeace56 in coroutine_trampoline.llvm ()
Cc: qemu-stable@nongnu.org
Buglink: https://issues.redhat.com/browse/RHEL-832
Signed-off-by: Kevin Wolf <kwolf@redhat.com>
Message-ID: <20230905145002.46391-3-kwolf@redhat.com>
Reviewed-by: Stefan Hajnoczi <stefanha@redhat.com>
Signed-off-by: Kevin Wolf <kwolf@redhat.com>
(cherry picked from commit 92e2e6a867334a990f8d29f07ca34e3162fdd6ec)
Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>
Commit: 53a4e7ef420a2e272907b98fd8ffc199bcdc0e06
https://github.com/qemu/qemu/commit/53a4e7ef420a2e272907b98fd8ffc199bcdc0e06
Author: Colton Lewis <coltonlewis@google.com>
Date: 2023-09-11 (Mon, 11 Sep 2023)
Changed paths:
M target/arm/kvm64.c
Log Message:
-----------
arm64: Restore trapless ptimer access
Due to recent KVM changes, QEMU is setting a ptimer offset resulting
in unintended trap and emulate access and a consequent performance
hit. Filter out the PTIMER_CNT register to restore trapless ptimer
access.
Quoting Andrew Jones:
Simply reading the CNT register and writing back the same value is
enough to set an offset, since the timer will have certainly moved
past whatever value was read by the time it's written. QEMU
frequently saves and restores all registers in the get-reg-list array,
unless they've been explicitly filtered out (with Linux commit
680232a94c12, KVM_REG_ARM_PTIMER_CNT is now in the array). So, to
restore trapless ptimer accesses, we need a QEMU patch to filter out
the register.
See
https://lore.kernel.org/kvmarm/gsntttsonus5.fsf@coltonlewis-kvm.c.googlers.com/T/#m0770023762a821db2a3f0dd0a7dc6aa54e0d0da9
for additional context.
Cc: qemu-stable@nongnu.org
Signed-off-by: Andrew Jones <andrew.jones@linux.dev>
Signed-off-by: Colton Lewis <coltonlewis@google.com>
Reviewed-by: Richard Henderson <richard.henderson@linaro.org>
Tested-by: Colton Lewis <coltonlewis@google.com>
Message-id: 20230831190052.129045-1-coltonlewis@google.com
Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
(cherry picked from commit 682814e2a3c883b27f24b9e7cab47313c49acbd4)
Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>
Commit: 3af03de983108bc8c60a1a274b3e81a9553d4ce1
https://github.com/qemu/qemu/commit/3af03de983108bc8c60a1a274b3e81a9553d4ce1
Author: Thomas Huth <thuth@redhat.com>
Date: 2023-09-12 (Tue, 12 Sep 2023)
Changed paths:
M hw/char/riscv_htif.c
Log Message:
-----------
hw/char/riscv_htif: Fix printing of console characters on big endian hosts
The character that should be printed is stored in the 64 bit "payload"
variable. The code currently tries to print it by taking the address
of the variable and passing this pointer to qemu_chr_fe_write(). However,
this only works on little endian hosts where the least significant bits
are stored on the lowest address. To do this in a portable way, we have
to store the value in an uint8_t variable instead.
Fixes: 5033606780 ("RISC-V HTIF Console")
Signed-off-by: Thomas Huth <thuth@redhat.com>
Reviewed-by: Alistair Francis <alistair.francis@wdc.com>
Reviewed-by: Bin Meng <bmeng@tinylab.org>
Reviewed-by: Daniel Henrique Barboza <dbarboza@ventanamicro.com>
Reviewed-by: Philippe Mathieu-Daudé <philmd@linaro.org>
Message-Id: <20230721094720.902454-2-thuth@redhat.com>
Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
(cherry picked from commit c255946e3df4d9660e4f468a456633c24393d468)
Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>
Commit: aeb931d82b13c50587268f462dcd46b23d2086ff
https://github.com/qemu/qemu/commit/aeb931d82b13c50587268f462dcd46b23d2086ff
Author: Thomas Huth <thuth@redhat.com>
Date: 2023-09-20 (Wed, 20 Sep 2023)
Changed paths:
M include/exec/cpu-all.h
A include/exec/tswap.h
Log Message:
-----------
include/exec: Provide the tswap() functions for target independent code, too
In some cases of target independent code, it would be useful to have access
to the functions that swap endianess in case it differs between guest and
host. Thus re-implement the tswapXX() functions in a new header that can be
included separately. The check whether the swapping is needed continues to
be done at compile-time for target specific code, while it is done at
run-time in target-independent code.
Message-Id: <20230411183418.1640500-3-thuth@redhat.com>
Reviewed-by: Richard Henderson <richard.henderson@linaro.org>
Reviewed-by: Cédric Le Goater <clg@kaod.org>
Signed-off-by: Thomas Huth <thuth@redhat.com>
(cherry picked from commit 24be3369ad63c3882be42dd510a45bad52816fd1)
Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>
(trivial change needed for the next commit 058096f1c5
"hw/char/riscv_htif: Fix the console syscall on big endian hosts")
Commit: a57e4cc6fe81a0b2ca8a32db91ca45df205c4a8f
https://github.com/qemu/qemu/commit/a57e4cc6fe81a0b2ca8a32db91ca45df205c4a8f
Author: Thomas Huth <thuth@redhat.com>
Date: 2023-09-20 (Wed, 20 Sep 2023)
Changed paths:
M hw/char/riscv_htif.c
Log Message:
-----------
hw/char/riscv_htif: Fix the console syscall on big endian hosts
Values that have been read via cpu_physical_memory_read() from the
guest's memory have to be swapped in case the host endianess differs
from the guest.
Fixes: a6e13e31d5 ("riscv_htif: Support console output via proxy syscall")
Signed-off-by: Thomas Huth <thuth@redhat.com>
Reviewed-by: Alistair Francis <alistair.francis@wdc.com>
Reviewed-by: Bin Meng <bmeng@tinylab.org>
Reviewed-by: Daniel Henrique Barboza <dbarboza@ventanamicro.com>
Message-Id: <20230721094720.902454-3-thuth@redhat.com>
Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
(cherry picked from commit 058096f1c55ab688db7e1d6814aaefc1bcd87f7a)
Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>
(Mjt: context fix in hw/char/riscv_htif.c for #include)
Commit: fd1a0c89c66c9e03b6cc7a1283856bb2112a9bde
https://github.com/qemu/qemu/commit/fd1a0c89c66c9e03b6cc7a1283856bb2112a9bde
Author: Jason Chien <jason.chien@sifive.com>
Date: 2023-09-20 (Wed, 20 Sep 2023)
Changed paths:
M hw/intc/riscv_aclint.c
Log Message:
-----------
hw/intc: Fix upper/lower mtime write calculation
When writing the upper mtime, we should keep the original lower mtime
whose value is given by cpu_riscv_read_rtc() instead of
cpu_riscv_read_rtc_raw(). The same logic applies to writes to lower mtime.
Signed-off-by: Jason Chien <jason.chien@sifive.com>
Reviewed-by: Alistair Francis <alistair.francis@wdc.com>
Message-ID: <20230728082502.26439-1-jason.chien@sifive.com>
Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
(cherry picked from commit e0922b73baf00c4c19d4ad30d09bb94f7ffea0f4)
Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>
Commit: c00a9ec0613ca428abaedaf8b7be7b1cbb97d37f
https://github.com/qemu/qemu/commit/c00a9ec0613ca428abaedaf8b7be7b1cbb97d37f
Author: Jason Chien <jason.chien@sifive.com>
Date: 2023-09-20 (Wed, 20 Sep 2023)
Changed paths:
M hw/intc/riscv_aclint.c
Log Message:
-----------
hw/intc: Make rtc variable names consistent
The variables whose values are given by cpu_riscv_read_rtc() should be named
"rtc". The variables whose value are given by cpu_riscv_read_rtc_raw()
should be named "rtc_r".
Signed-off-by: Jason Chien <jason.chien@sifive.com>
Reviewed-by: Alistair Francis <alistair.francis@wdc.com>
Message-ID: <20230728082502.26439-2-jason.chien@sifive.com>
Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
(cherry picked from commit 9382a9eafccad8dc6a487ea3a8d2bed03dc35db9)
Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>
Commit: 9bac2bcf10e25506cc1fc7b69b027399afeb3768
https://github.com/qemu/qemu/commit/9bac2bcf10e25506cc1fc7b69b027399afeb3768
Author: LIU Zhiwei <zhiwei_liu@linux.alibaba.com>
Date: 2023-09-20 (Wed, 20 Sep 2023)
Changed paths:
M linux-user/riscv/signal.c
Log Message:
-----------
linux-user/riscv: Use abi type for target_ucontext
We should not use types dependend on host arch for target_ucontext.
This bug is found when run rv32 applications.
Signed-off-by: LIU Zhiwei <zhiwei_liu@linux.alibaba.com>
Reviewed-by: Richard Henderson <richard.henderson@linaro.org>
Reviewed-by: Daniel Henrique Barboza <dbarboza@ventanamicro.com>
Reviewed-by: Philippe Mathieu-Daudé <philmd@linaro.org>
Message-ID: <20230811055438.1945-1-zhiwei_liu@linux.alibaba.com>
Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
(cherry picked from commit ae7d4d625cab49657b9fc2be09d895afb9bcdaf0)
Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>
Commit: e94ea3c6dbd48d70edca6de0079d5690a82ec35b
https://github.com/qemu/qemu/commit/e94ea3c6dbd48d70edca6de0079d5690a82ec35b
Author: Conor Dooley <conor.dooley@microchip.com>
Date: 2023-09-20 (Wed, 20 Sep 2023)
Changed paths:
M hw/riscv/virt.c
Log Message:
-----------
hw/riscv: virt: Fix riscv,pmu DT node path
On a dtb dumped from the virt machine, dt-validate complains:
soc: pmu: {'riscv,event-to-mhpmcounters': [[1, 1, 524281], [2, 2, 524284],
[65561, 65561, 524280], [65563, 65563, 524280], [65569, 65569, 524280]],
'compatible': ['riscv,pmu']} should not be valid under {'type': 'object'}
from schema $id: http://devicetree.org/schemas/simple-bus.yaml#
That's pretty cryptic, but running the dtb back through dtc produces
something a lot more reasonable:
Warning (simple_bus_reg): /soc/pmu: missing or empty reg/ranges property
Moving the riscv,pmu node out of the soc bus solves the problem.
Signed-off-by: Conor Dooley <conor.dooley@microchip.com>
Acked-by: Alistair Francis <alistair.francis@wdc.com>
Reviewed-by: Daniel Henrique Barboza <dbarboza@ventanamicro.com>
Message-ID: <20230727-groom-decline-2c57ce42841c@spud>
Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
(cherry picked from commit 9ff31406312500053ecb5f92df01dd9ce52e635d)
Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>
Commit: 1805e05db3c6d92c750427b1c1371f44fa8e4893
https://github.com/qemu/qemu/commit/1805e05db3c6d92c750427b1c1371f44fa8e4893
Author: Daniel Henrique Barboza <dbarboza@ventanamicro.com>
Date: 2023-09-20 (Wed, 20 Sep 2023)
Changed paths:
M target/riscv/cpu.c
Log Message:
-----------
target/riscv: fix satp_mode_finalize() when satp_mode.supported = 0
In the same emulated RISC-V host, the 'host' KVM CPU takes 4 times
longer to boot than the 'rv64' KVM CPU.
The reason is an unintended behavior of riscv_cpu_satp_mode_finalize()
when satp_mode.supported = 0, i.e. when cpu_init() does not set
satp_mode_max_supported(). satp_mode_max_from_map(map) does:
31 - __builtin_clz(map)
This means that, if satp_mode.supported = 0, satp_mode_supported_max
wil be '31 - 32'. But this is C, so satp_mode_supported_max will gladly
set it to UINT_MAX (4294967295). After that, if the user didn't set a
satp_mode, set_satp_mode_default_map(cpu) will make
cfg.satp_mode.map = cfg.satp_mode.supported
So satp_mode.map = 0. And then satp_mode_map_max will be set to
satp_mode_max_from_map(cpu->cfg.satp_mode.map), i.e. also UINT_MAX. The
guard "satp_mode_map_max > satp_mode_supported_max" doesn't protect us
here since both are UINT_MAX.
And finally we have 2 loops:
for (int i = satp_mode_map_max - 1; i >= 0; --i) {
Which are, in fact, 2 loops from UINT_MAX -1 to -1. This is where the
extra delay when booting the 'host' CPU is coming from.
Commit 43d1de32f8 already set a precedence for satp_mode.supported = 0
in a different manner. We're doing the same here. If supported == 0,
interpret as 'the CPU wants the OS to handle satp mode alone' and skip
satp_mode_finalize().
We'll also put a guard in satp_mode_max_from_map() to assert out if map
is 0 since the function is not ready to deal with it.
Cc: Alexandre Ghiti <alexghiti@rivosinc.com>
Fixes: 6f23aaeb9b ("riscv: Allow user to set the satp mode")
Signed-off-by: Daniel Henrique Barboza <dbarboza@ventanamicro.com>
Reviewed-by: Andrew Jones <ajones@ventanamicro.com>
Message-ID: <20230817152903.694926-1-dbarboza@ventanamicro.com>
Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
(cherry picked from commit 3a2fc23563885c219c73c8f24318921daf02f3f2)
Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>
Commit: 70c97e75d709eadf80845259ea0a0409475102c3
https://github.com/qemu/qemu/commit/70c97e75d709eadf80845259ea0a0409475102c3
Author: Leon Schuermann <leons@opentitan.org>
Date: 2023-09-20 (Wed, 20 Sep 2023)
Changed paths:
M target/riscv/pmp.c
Log Message:
-----------
target/riscv/pmp.c: respect mseccfg.RLB for pmpaddrX changes
When the rule-lock bypass (RLB) bit is set in the mseccfg CSR, the PMP
configuration lock bits must not apply. While this behavior is
implemented for the pmpcfgX CSRs, this bit is not respected for
changes to the pmpaddrX CSRs. This patch ensures that pmpaddrX CSR
writes work even on locked regions when the global rule-lock bypass is
enabled.
Signed-off-by: Leon Schuermann <leons@opentitan.org>
Reviewed-by: Mayuresh Chitale <mchitale@ventanamicro.com>
Reviewed-by: Alistair Francis <alistair.francis@wdc.com>
Message-ID: <20230829215046.1430463-1-leon@is.currently.online>
Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
(cherry picked from commit 4e3adce1244e1ca30ec05874c3eca14911dc0825)
Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>
Commit: 36540b367eb80f1d6a646f691e6a2b75bf57ad61
https://github.com/qemu/qemu/commit/36540b367eb80f1d6a646f691e6a2b75bf57ad61
Author: Stefan Berger <stefanb@linux.ibm.com>
Date: 2023-09-20 (Wed, 20 Sep 2023)
Changed paths:
M hw/tpm/tpm_tis_sysbus.c
Log Message:
-----------
hw/tpm: TIS on sysbus: Remove unsupport ppi command line option
The ppi command line option for the TIS device on sysbus never worked
and caused an immediate segfault. Remove support for it since it also
needs support in the firmware and needs testing inside the VM.
Reproducer with the ppi=on option passed:
qemu-system-aarch64 \
-machine virt,gic-version=3 \
-m 4G \
-nographic -no-acpi \
-chardev socket,id=chrtpm,path=/tmp/mytpm1/swtpm-sock \
-tpmdev emulator,id=tpm0,chardev=chrtpm \
-device tpm-tis-device,tpmdev=tpm0,ppi=on
[...]
Segmentation fault (core dumped)
Signed-off-by: Stefan Berger <stefanb@linux.ibm.com>
Reviewed-by: Eric Auger <eric.auger@redhat.com>
Message-id: 20230713171955.149236-1-stefanb@linux.ibm.com
(cherry picked from commit 4c46fe2ed492f35f411632c8b5a8442f322bc3f0)
Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>
Commit: 6c575436cd3e692079fc3e2fe4f54efe77211549
https://github.com/qemu/qemu/commit/6c575436cd3e692079fc3e2fe4f54efe77211549
Author: Marc-André Lureau <marcandre.lureau@redhat.com>
Date: 2023-09-20 (Wed, 20 Sep 2023)
Changed paths:
M ui/console.c
Log Message:
-----------
ui: fix crash when there are no active_console
Thread 1 "qemu-system-x86" received signal SIGSEGV, Segmentation fault.
0x0000555555888630 in dpy_ui_info_supported (con=0x0) at ../ui/console.c:812
812 return con->hw_ops->ui_info != NULL;
(gdb) bt
#0 0x0000555555888630 in dpy_ui_info_supported (con=0x0) at ../ui/console.c:812
#1 0x00005555558a44b1 in protocol_client_msg (vs=0x5555578c76c0,
data=0x5555581e93f0 <incomplete sequence \373>, len=24) at ../ui/vnc.c:2585
#2 0x00005555558a19ac in vnc_client_read (vs=0x5555578c76c0) at
../ui/vnc.c:1607
#3 0x00005555558a1ac2 in vnc_client_io (ioc=0x5555581eb0e0, condition=G_IO_IN,
opaque=0x5555578c76c0) at ../ui/vnc.c:1635
Fixes:
https://issues.redhat.com/browse/RHEL-2600
Signed-off-by: Marc-André Lureau <marcandre.lureau@redhat.com>
Reviewed-by: Albert Esteve <aesteve@redhat.com>
(cherry picked from commit 48a35e12faf90a896c5aa4755812201e00d60316)
Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>
Commit: 0ef930a29f432320d979e227a305f927bb15eb09
https://github.com/qemu/qemu/commit/0ef930a29f432320d979e227a305f927bb15eb09
Author: Janosch Frank <frankja@linux.ibm.com>
Date: 2023-09-20 (Wed, 20 Sep 2023)
Changed paths:
M hw/s390x/s390-virtio-ccw.c
Log Message:
-----------
s390x/ap: fix missing subsystem reset registration
A subsystem reset contains a reset of AP resources which has been
missing. Adding the AP bridge to the list of device types that need
reset fixes this issue.
Reviewed-by: Jason J. Herne <jjherne@linux.ibm.com>
Reviewed-by: Tony Krowiak <akrowiak@linux.ibm.com>
Signed-off-by: Janosch Frank <frankja@linux.ibm.com>
Fixes: a51b3153 ("s390x/ap: base Adjunct Processor (AP) object model")
Message-ID: <20230823142219.1046522-2-seiden@linux.ibm.com>
Signed-off-by: Thomas Huth <thuth@redhat.com>
(cherry picked from commit 297ec01f0b9864ea8209ca0ddc6643b4c0574bdb)
Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>
Commit: fcf58d6f20d29ee250f542ac8de968700c957134
https://github.com/qemu/qemu/commit/fcf58d6f20d29ee250f542ac8de968700c957134
Author: Marc-André Lureau <marcandre.lureau@redhat.com>
Date: 2023-09-20 (Wed, 20 Sep 2023)
Changed paths:
M backends/tpm/tpm_util.c
Log Message:
-----------
tpm: fix crash when FD >= 1024 and unnecessary errors due to EINTR
Replace select() with poll() to fix a crash when QEMU has a large number
of FDs. Also use RETRY_ON_EINTR to avoid unnecessary errors due to EINTR.
Cc: qemu-stable@nongnu.org
Fixes: https://bugzilla.redhat.com/show_bug.cgi?id=2020133
Fixes: 56a3c24ffc ("tpm: Probe for connected TPM 1.2 or TPM 2")
Signed-off-by: Marc-André Lureau <marcandre.lureau@redhat.com>
Reviewed-by: Michael Tokarev <mjt@tls.msk.ru>
Reviewed-by: Stefan Berger <stefanb@linux.ibm.com>
Signed-off-by: Stefan Berger <stefanb@linux.ibm.com>
(cherry picked from commit 8e32ddff69b6b4547cc00592ad816484e160817a)
Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>
Commit: 6bbce8b464206e6622216b62841cb3e953d56eb8
https://github.com/qemu/qemu/commit/6bbce8b464206e6622216b62841cb3e953d56eb8
Author: Michael Tokarev <mjt@tls.msk.ru>
Date: 2023-09-21 (Thu, 21 Sep 2023)
Changed paths:
M VERSION
Log Message:
-----------
Update version for 8.0.5 release
Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>
Compare: https://github.com/qemu/qemu/compare/83a9cdbd65ce...6bbce8b46420