[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Qemu-commits] [qemu/qemu] a629fe: block: Fix crash when loading snapsho
|
From: |
Alex Bennée |
|
Subject: |
[Qemu-commits] [qemu/qemu] a629fe: block: Fix crash when loading snapshot on inactive... |
|
Date: |
Mon, 29 Jan 2024 07:24:29 -0800 |
Branch: refs/heads/stable-7.2
Home: https://github.com/qemu/qemu
Commit: a629fee99ba2189a7452a212f0a01696a65877ac
https://github.com/qemu/qemu/commit/a629fee99ba2189a7452a212f0a01696a65877ac
Author: Kevin Wolf <kwolf@redhat.com>
Date: 2023-12-22 (Fri, 22 Dec 2023)
Changed paths:
M block/snapshot.c
Log Message:
-----------
block: Fix crash when loading snapshot on inactive node
bdrv_is_read_only() only checks if the node is configured to be
read-only eventually, but even if it returns false, writing to the node
may not be permitted at the moment (because it's inactive).
bdrv_is_writable() checks that the node can be written to right now, and
this is what the snapshot operations really need.
Change bdrv_can_snapshot() to use bdrv_is_writable() to fix crashes like
the following:
$ ./qemu-system-x86_64 -hda /tmp/test.qcow2 -loadvm foo -incoming defer
qemu-system-x86_64: ../block/io.c:1990: int bdrv_co_write_req_prepare(BdrvChild
*, int64_t, int64_t, BdrvTrackedRequest *, int): Assertion `!(bs->open_flags &
BDRV_O_INACTIVE)' failed.
The resulting error message after this patch isn't perfect yet, but at
least it doesn't crash any more:
$ ./qemu-system-x86_64 -hda /tmp/test.qcow2 -loadvm foo -incoming defer
qemu-system-x86_64: Device 'ide0-hd0' is writable but does not support snapshots
Signed-off-by: Kevin Wolf <kwolf@redhat.com>
Message-ID: <20231201142520.32255-2-kwolf@redhat.com>
Signed-off-by: Kevin Wolf <kwolf@redhat.com>
(cherry picked from commit d3007d348adaaf04ee8b099a475282034a662414)
Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>
Commit: ad24078e3fc4330647b5d0e0c95db7bec86136a5
https://github.com/qemu/qemu/commit/ad24078e3fc4330647b5d0e0c95db7bec86136a5
Author: Kevin Wolf <kwolf@redhat.com>
Date: 2023-12-22 (Fri, 22 Dec 2023)
Changed paths:
M softmmu/vl.c
Log Message:
-----------
vl: Improve error message for conflicting -incoming and -loadvm
Currently, the conflict between -incoming and -loadvm is only detected
when loading the snapshot fails because the image is still inactive for
the incoming migration. This results in a suboptimal error message:
$ ./qemu-system-x86_64 -hda /tmp/test.qcow2 -loadvm foo -incoming defer
qemu-system-x86_64: Device 'ide0-hd0' is writable but does not support snapshots
Catch the situation already in qemu_validate_options() to improve the
message:
$ ./qemu-system-x86_64 -hda /tmp/test.qcow2 -loadvm foo -incoming defer
qemu-system-x86_64: 'incoming' and 'loadvm' options are mutually exclusive
Signed-off-by: Kevin Wolf <kwolf@redhat.com>
Message-ID: <20231201142520.32255-3-kwolf@redhat.com>
Signed-off-by: Kevin Wolf <kwolf@redhat.com>
(cherry picked from commit 5a7f21efaf99c60614fe1967be1c0f9aa46c526e)
Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>
Commit: c6f64736dea20eaf165704967a12ce030de5b84b
https://github.com/qemu/qemu/commit/c6f64736dea20eaf165704967a12ce030de5b84b
Author: Kevin Wolf <kwolf@redhat.com>
Date: 2023-12-22 (Fri, 22 Dec 2023)
Changed paths:
A tests/qemu-iotests/tests/qcow2-internal-snapshots
A tests/qemu-iotests/tests/qcow2-internal-snapshots.out
Log Message:
-----------
iotests: Basic tests for internal snapshots
We have a few test cases that include tests for corner case aspects of
internal snapshots, but nothing that tests that they actually function
as snapshots or that involves deleting a snapshot. Add a test for this
kind of basic internal snapshot functionality.
The error cases include a regression test for the crash we just fixed
with snapshot operations on inactive images.
Signed-off-by: Kevin Wolf <kwolf@redhat.com>
Message-ID: <20231201142520.32255-4-kwolf@redhat.com>
Signed-off-by: Kevin Wolf <kwolf@redhat.com>
(cherry picked from commit bb6e2511eb48539b7dcbcb5f47772e156b9c45d1)
Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>
Commit: 0eab8d42e193d176b9e7aaba2fbaf8b556d7fd0f
https://github.com/qemu/qemu/commit/0eab8d42e193d176b9e7aaba2fbaf8b556d7fd0f
Author: Xu Lu <luxu.kernel@bytedance.com>
Date: 2024-01-08 (Mon, 08 Jan 2024)
Changed paths:
M target/riscv/csr.c
Log Message:
-----------
target/riscv: Fix mcycle/minstret increment behavior
The mcycle/minstret counter's stop flag is mistakenly updated on a copy
on stack. Thus the counter increments even when the CY/IR bit in the
mcountinhibit register is set. This commit corrects its behavior.
Fixes: 3780e33732f88 (target/riscv: Support mcycle/minstret write operation)
Signed-off-by: Xu Lu <luxu.kernel@bytedance.com>
Reviewed-by: Daniel Henrique Barboza <dbarboza@ventanamicro.com>
Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>
(cherry picked from commit 5cb0e7abe1635cb82e0033260dac2b910d142f8c)
Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>
Commit: c0a2b77dd88c29b98a7a51c383b8c3a81340bd80
https://github.com/qemu/qemu/commit/c0a2b77dd88c29b98a7a51c383b8c3a81340bd80
Author: Michael Tokarev <mjt@tls.msk.ru>
Date: 2024-01-08 (Mon, 08 Jan 2024)
Changed paths:
M chardev/char.c
Log Message:
-----------
chardev/char.c: fix "abstract device type" error message
Current error message:
qemu-system-x86_64: -chardev spice,id=foo: Parameter 'driver' expects an
abstract device type
while in fact the meaning is in reverse, -chardev expects
a non-abstract device type.
Fixes: 777357d758d9 ("chardev: qom-ify" 2016-12-07)
Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>
Reviewed-by: Zhao Liu <zhao1.liu@intel.com>
(cherry picked from commit 4ad87cd4b2254197b7ac12e3da824854e6a90f8f)
Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>
Commit: dbf80fdef803c737938a73bfc5257a8542bf3375
https://github.com/qemu/qemu/commit/dbf80fdef803c737938a73bfc5257a8542bf3375
Author: Peter Maydell <peter.maydell@linaro.org>
Date: 2024-01-11 (Thu, 11 Jan 2024)
Changed paths:
M hw/intc/arm_gicv3_cpuif.c
Log Message:
-----------
hw/intc/arm_gicv3_cpuif: handle LPIs in in the list registers
The hypervisor can deliver (virtual) LPIs to a guest by setting up a
list register to have an intid which is an LPI. The GIC has to treat
these a little differently to standard interrupt IDs, because LPIs
have no Active state, and so the guest will only EOI them, it will
not also deactivate them. So icv_eoir_write() must do two things:
* if the LPI ID is not in any list register, we drop the
priority but do not increment the EOI count
* if the LPI ID is in a list register, we immediately deactivate
it, regardless of the split-drop-and-deactivate control
This can be seen in the VirtualWriteEOIR0() and VirtualWriteEOIR1()
pseudocode in the GICv3 architecture specification.
Without this fix, potentially a hypervisor guest might stall because
LPIs get stuck in a bogus Active+Pending state.
Cc: qemu-stable@nongnu.org
Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
Reviewed-by: Richard Henderson <richard.henderson@linaro.org>
Tested-by: Miguel Luis <miguel.luis@oracle.com>
(cherry picked from commit 82a65e3188abebb509510b391726711606aca642)
Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>
Commit: 9222f3ee43743d4c02d4db1bdc5181bb78a8afe7
https://github.com/qemu/qemu/commit/9222f3ee43743d4c02d4db1bdc5181bb78a8afe7
Author: Ilya Leoshkevich <iii@linux.ibm.com>
Date: 2024-01-13 (Sat, 13 Jan 2024)
Changed paths:
M target/s390x/tcg/translate.c
Log Message:
-----------
target/s390x: Fix LAE setting a wrong access register
LAE should set the access register corresponding to the first operand,
instead, it always modifies access register 1.
Co-developed-by: Ido Plat <Ido.Plat@ibm.com>
Cc: qemu-stable@nongnu.org
Fixes: a1c7610a6879 ("target-s390x: implement LAY and LAEY instructions")
Reviewed-by: David Hildenbrand <david@redhat.com>
Signed-off-by: Ilya Leoshkevich <iii@linux.ibm.com>
Message-ID: <20240111092328.929421-2-iii@linux.ibm.com>
Signed-off-by: Thomas Huth <thuth@redhat.com>
(cherry picked from commit e358a25a97c71c39e3513d9b869cdb82052e50b8)
Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>
(Mjt: target/s390x/tcg/translate.c: fixup for
v8.1.0-1189-gad75a51e84 "tcg: Rename cpu_env to tcg_env" and
v7.2.0-2636-g3ac6f91bca "target/s390x: Drop tcg_temp_free from translate.c")
Commit: c59ce9fef694fff56394ef4a8983c67464286ee9
https://github.com/qemu/qemu/commit/c59ce9fef694fff56394ef4a8983c67464286ee9
Author: Peter Maydell <peter.maydell@linaro.org>
Date: 2024-01-13 (Sat, 13 Jan 2024)
Changed paths:
M .gitlab-ci.d/buildtest.yml
Log Message:
-----------
.gitlab-ci.d/buildtest.yml: Work around htags bug when environment is large
Sometimes the CI "pages" job fails with a message like this from
htags:
$ htags -anT --tree-view=filetree -m qemu_init -t "Welcome to the QEMU
sourcecode"
htags: Negative exec line limit = -371
This is due to a bug in hflags where if the environment is too large it
falls over:
https://lists.gnu.org/archive/html/bug-global/2024-01/msg00000.html
This happens to us because GitLab CI puts the commit message of the
commit under test into the CI_COMMIT_MESSAGE and/or CI_COMMIT_TAG_MESSAGE
environment variables, so the job will fail if the commit happens to
have a verbose commit message.
Work around the htags bug by unsetting these variables while running
htags.
Cc: qemu-stable@nongnu.org
Resolves: https://gitlab.com/qemu-project/qemu/-/issues/2080
Reviewed-by: Philippe Mathieu-Daudé <philmd@linaro.org>
Message-ID: <20240111125543.1573473-1-peter.maydell@linaro.org>
Signed-off-by: Thomas Huth <thuth@redhat.com>
(cherry picked from commit 52a21689cd829c1cc931b59b5ee5bdb10dd578c1)
Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>
Commit: 2ad4ebb350fa3340488f2bb9c751726e449597e1
https://github.com/qemu/qemu/commit/2ad4ebb350fa3340488f2bb9c751726e449597e1
Author: Anastasia Belova <abelova@astralinux.ru>
Date: 2024-01-19 (Fri, 19 Jan 2024)
Changed paths:
M include/hw/elf_ops.h
Log Message:
-----------
load_elf: fix iterator's type for elf file processing
j is used while loading an ELF file to byteswap segments'
data. If data is larger than 2GB an overflow may happen.
So j should be elf_word.
This commit fixes a minor bug: it's unlikely anybody is trying to
load ELF files with 2GB+ segments for wrong-endianness targets,
but if they did, it wouldn't work correctly.
Found by Linux Verification Center (linuxtesting.org) with SVACE.
Cc: qemu-stable@nongnu.org
Fixes: 7ef295ea5b ("loader: Add data swap option to load-elf")
Signed-off-by: Anastasia Belova <abelova@astralinux.ru>
Reviewed-by: Peter Maydell <peter.maydell@linaro.org>
Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
(cherry picked from commit 410c2a4d75f52f6a2fe978eda5a9b6f854afe5ea)
Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>
Commit: 15e207b9ed89c843639f8674f318b50569869de7
https://github.com/qemu/qemu/commit/15e207b9ed89c843639f8674f318b50569869de7
Author: Richard Henderson <richard.henderson@linaro.org>
Date: 2024-01-20 (Sat, 20 Jan 2024)
Changed paths:
M target/i386/cpu.h
M target/i386/tcg/tcg-cpu.c
M target/i386/tcg/translate.c
Log Message:
-----------
target/i386: Fix 32-bit wrapping of pc/eip computation
In 32-bit mode, pc = eip + cs_base is also 32-bit, and must wrap.
Failure to do so results in incorrect memory exceptions to the guest.
Before 732d548732ed, this was implicitly done via truncation to
target_ulong but only in qemu-system-i386, not qemu-system-x86_64.
To fix this, we must add conditional zero-extensions.
Since we have to test for 32 vs 64-bit anyway, note that cs_base
is always zero in 64-bit mode.
Resolves: https://gitlab.com/qemu-project/qemu/-/issues/2022
Signed-off-by: Richard Henderson <richard.henderson@linaro.org>
Reviewed-by: Paolo Bonzini <pbonzini@redhat.com>
Message-Id: <20231212172510.103305-1-richard.henderson@linaro.org>
(cherry picked from commit b5e0d5d22fbffc3d8f7d3e86d7a2d05a1a974e27)
Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>
(Mjt: context fix in target/i386/tcg/tcg-cpu.c for v8.1.0-1190-gb77af26e97
"accel/tcg: Replace CPUState.env_ptr with cpu_env()")
(Mjt: fixup in target/i386/tcg/tcg-cpu.c for v7.2.0-1854-g34a39c2443
"target/i386: Replace `tb_pc()` with `tb->pc`")
Commit: 6abbb26bbc8a7779876b70e184a2123f34531f0b
https://github.com/qemu/qemu/commit/6abbb26bbc8a7779876b70e184a2123f34531f0b
Author: Richard Henderson <richard.henderson@linaro.org>
Date: 2024-01-20 (Sat, 20 Jan 2024)
Changed paths:
M target/i386/tcg/translate.c
Log Message:
-----------
target/i386: Do not re-compute new pc with CF_PCREL
With PCREL, we have a page-relative view of EIP, and an
approximation of PC = EIP+CSBASE that is good enough to
detect page crossings. If we try to recompute PC after
masking EIP, we will mess up that approximation and write
a corrupt value to EIP.
We already handled masking properly for PCREL, so the
fix in b5e0d5d2 was only needed for the !PCREL path.
Cc: qemu-stable@nongnu.org
Fixes: b5e0d5d22fbf ("target/i386: Fix 32-bit wrapping of pc/eip computation")
Reported-by: Michael Tokarev <mjt@tls.msk.ru>
Signed-off-by: Richard Henderson <richard.henderson@linaro.org>
Message-ID: <20240101230617.129349-1-richard.henderson@linaro.org>
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
(cherry picked from commit a58506b748b8988a95f4fa1a2420ac5c17038b30)
Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>
Commit: 7d6aebaec5d6eade830f2d08dc0b2bf7f5eee3b4
https://github.com/qemu/qemu/commit/7d6aebaec5d6eade830f2d08dc0b2bf7f5eee3b4
Author: guoguangyao <guoguangyao18@mails.ucas.ac.cn>
Date: 2024-01-20 (Sat, 20 Jan 2024)
Changed paths:
M target/i386/tcg/translate.c
Log Message:
-----------
target/i386: fix incorrect EIP in PC-relative translation blocks
The PCREL patches introduced a bug when updating EIP in the !CF_PCREL case.
Using s->pc in func gen_update_eip_next() solves the problem.
Cc: qemu-stable@nongnu.org
Fixes: b5e0d5d22fbf ("target/i386: Fix 32-bit wrapping of pc/eip computation")
Signed-off-by: guoguangyao <guoguangyao18@mails.ucas.ac.cn>
Reviewed-by: Richard Henderson <richard.henderson@linaro.org>
Message-ID: <20240115020804.30272-1-guoguangyao18@mails.ucas.ac.cn>
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
(cherry picked from commit 2926eab8969908bc068629e973062a0fb6ff3759)
Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>
Commit: a290e43f5868f1276fdbb4fc66fe49c28fd5fa9a
https://github.com/qemu/qemu/commit/a290e43f5868f1276fdbb4fc66fe49c28fd5fa9a
Author: Paolo Bonzini <pbonzini@redhat.com>
Date: 2024-01-20 (Sat, 20 Jan 2024)
Changed paths:
M target/i386/tcg/tcg-cpu.c
M target/i386/tcg/translate.c
Log Message:
-----------
target/i386: pcrel: store low bits of physical address in data[0]
For PC-relative translation blocks, env->eip changes during the
execution of a translation block, Therefore, QEMU must be able to
recover an instruction's PC just from the TranslationBlock struct and
the instruction data with. Because a TB will not span two pages, QEMU
stores all the low bits of EIP in the instruction data and replaces them
in x86_restore_state_to_opc. Bits 12 and higher (which may vary between
executions of a PCREL TB, since these only use the physical address in
the hash key) are kept unmodified from env->eip. The assumption is that
these bits of EIP, unlike bits 0-11, will not change as the translation
block executes.
Unfortunately, this is incorrect when the CS base is not aligned to a page.
Then the linear address of the instructions (i.e. the one with the
CS base addred) indeed will never span two pages, but bits 12+ of EIP
can actually change. For example, if CS base is 0x80262200 and EIP =
0x6FF4, the first instruction in the translation block will be at linear
address 0x802691F4. Even a very small TB will cross to EIP = 0x7xxx,
while the linear addresses will remain comfortably within a single page.
The fix is simply to use the low bits of the linear address for data[0],
since those don't change. Then x86_restore_state_to_opc uses tb->cs_base
to compute a temporary linear address (referring to some unknown
instruction in the TB, but with the correct values of bits 12 and higher);
the low bits are replaced with data[0], and EIP is obtained by subtracting
again the CS base.
Huge thanks to Mark Cave-Ayland for the image and initial debugging,
and to Gitlab user @kjliew for help with bisecting another occurrence
of (hopefully!) the same bug.
It should be relatively easy to write a testcase that performs MMIO on
an EIP with different bits 12+ than the first instruction of the translation
block; any help is welcome.
Fixes: e3a79e0e878 ("target/i386: Enable TARGET_TB_PCREL", 2022-10-11)
Cc: qemu-stable@nongnu.org
Cc: Mark Cave-Ayland <mark.cave-ayland@ilande.co.uk>
Cc: Richard Henderson <richard.henderson@linaro.org>
Resolves: https://gitlab.com/qemu-project/qemu/-/issues/1759
Resolves: https://gitlab.com/qemu-project/qemu/-/issues/1964
Resolves: https://gitlab.com/qemu-project/qemu/-/issues/2012
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
(cherry picked from commit 729ba8e933f8af5800c3a92b37e630e9bdaa9f1e)
Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>
(Mjt: fixup in target/i386/tcg/tcg-cpu.c target/i386/tcg/translate.c for
v7.2.0-1839-g2e3afe8e19 "target/i386: Replace `TARGET_TB_PCREL` with
`CF_PCREL`")
Commit: 06679ac8b565b4485516336c497089d8ca2496f0
https://github.com/qemu/qemu/commit/06679ac8b565b4485516336c497089d8ca2496f0
Author: Gerd Hoffmann <kraxel@redhat.com>
Date: 2024-01-20 (Sat, 20 Jan 2024)
Changed paths:
M hw/block/pflash_cfi01.c
Log Message:
-----------
hw/pflash: refactor pflash_data_write()
Move the offset calculation, do it once at the start of the function and
let the 'p' variable point directly to the memory location which should
be updated. This makes it simpler to update other buffers than
pfl->storage in an upcoming patch. No functional change.
Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
Reviewed-by: Philippe Mathieu-Daudé <philmd@linaro.org>
Message-ID: <20240108160900.104835-2-kraxel@redhat.com>
Signed-off-by: Philippe Mathieu-Daudé <philmd@linaro.org>
(cherry picked from commit 3b14a555fdb627ac091559ef5931c887d06590d8)
Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>
Commit: d56cc9b5e527fcc696616b7bedef24ae924c918c
https://github.com/qemu/qemu/commit/d56cc9b5e527fcc696616b7bedef24ae924c918c
Author: Gerd Hoffmann <kraxel@redhat.com>
Date: 2024-01-20 (Sat, 20 Jan 2024)
Changed paths:
M hw/block/pflash_cfi01.c
Log Message:
-----------
hw/pflash: use ldn_{be,le}_p and stn_{be,le}_p
Use the helper functions we have to read/write multi-byte values
in correct byte order.
Suggested-by: Philippe Mathieu-Daudé <philmd@linaro.org>
Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
Reviewed-by: Philippe Mathieu-Daudé <philmd@linaro.org>
Message-ID: <20240108160900.104835-3-kraxel@redhat.com>
Signed-off-by: Philippe Mathieu-Daudé <philmd@linaro.org>
(cherry picked from commit 5dd58358a57048e5ceabf5c91c0544f4f56afdcd)
Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>
Commit: 16f6a650a8174f1582c14f00c746483fc9a99f3a
https://github.com/qemu/qemu/commit/16f6a650a8174f1582c14f00c746483fc9a99f3a
Author: Gerd Hoffmann <kraxel@redhat.com>
Date: 2024-01-20 (Sat, 20 Jan 2024)
Changed paths:
M hw/block/pflash_cfi01.c
M hw/block/pflash_cfi02.c
M hw/block/trace-events
Log Message:
-----------
hw/pflash: implement update buffer for block writes
Add an update buffer where all block updates are staged.
Flush or discard updates properly, so we should never see
half-completed block writes in pflash storage.
Drop a bunch of FIXME comments ;)
Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
Reviewed-by: Philippe Mathieu-Daudé <philmd@linaro.org>
Message-ID: <20240108160900.104835-4-kraxel@redhat.com>
Signed-off-by: Philippe Mathieu-Daudé <philmd@linaro.org>
(cherry picked from commit 284a7ee2e290e0c9b8cd3ea6164d92386933054f)
Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>
(Mjt: drop const in hw/block/pflash_cfi01.c for before
v8.2.0-220-g7d5dc0a367 "hw/block: Constify VMState")
Commit: 528496a5d4a2667869f07bdd1ec46f4d41171975
https://github.com/qemu/qemu/commit/528496a5d4a2667869f07bdd1ec46f4d41171975
Author: Mark Cave-Ayland <mark.cave-ayland@ilande.co.uk>
Date: 2024-01-20 (Sat, 20 Jan 2024)
Changed paths:
M hw/scsi/esp-pci.c
Log Message:
-----------
hw/scsi/esp-pci: use correct address register for PCI DMA transfers
The current code in esp_pci_dma_memory_rw() sets the DMA address to the value
of the DMA_SPA (Starting Physical Address) register which is incorrect: this
means that for each callback from the SCSI layer the DMA address is set back
to the starting address.
In the case where only a single SCSI callback occurs (currently for transfer
lengths < 128kB) this works fine, however for larger transfers the DMA address
wraps back to the initial starting address, corrupting the buffer holding the
data transferred to the guest.
Fix esp_pci_dma_memory_rw() to use the DMA_WAC (Working Address Counter) for
the DMA address which is correctly incremented across multiple SCSI layer
transfers.
Signed-off-by: Mark Cave-Ayland <mark.cave-ayland@ilande.co.uk>
Reviewed-by: Guenter Roeck <linux@roeck-us.net>
Tested-by: Guenter Roeck <linux@roeck-us.net>
Message-ID: <20240112131529.515642-2-mark.cave-ayland@ilande.co.uk>
Signed-off-by: Philippe Mathieu-Daudé <philmd@linaro.org>
(cherry picked from commit 84a6835e004c257037492167d4f266dbb54dc33e)
Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>
Commit: fd4e677c793855057a6204e1931eb927590f85f3
https://github.com/qemu/qemu/commit/fd4e677c793855057a6204e1931eb927590f85f3
Author: Mark Cave-Ayland <mark.cave-ayland@ilande.co.uk>
Date: 2024-01-20 (Sat, 20 Jan 2024)
Changed paths:
M hw/scsi/esp-pci.c
Log Message:
-----------
hw/scsi/esp-pci: generate PCI interrupt from separate ESP and PCI sources
The am53c974/dc390 PCI interrupt has two separate sources: the first is from the
internal ESP device, and the second is from the PCI DMA transfer logic.
Update the ESP interrupt handler so that it sets DMA_STAT_SCSIINT rather than
driving the PCI IRQ directly, and introduce a new esp_pci_update_irq() function
to generate the correct PCI IRQ level. In particular this fixes spurious
interrupts
being generated by setting DMA_STAT_DONE at the end of a transfer if
DMA_CMD_INTE_D
isn't set in the DMA_CMD register.
Signed-off-by: Mark Cave-Ayland <mark.cave-ayland@ilande.co.uk>
Reviewed-by: Guenter Roeck <linux@roeck-us.net>
Tested-by: Guenter Roeck <linux@roeck-us.net>
Message-ID: <20240112131529.515642-3-mark.cave-ayland@ilande.co.uk>
Signed-off-by: Philippe Mathieu-Daudé <philmd@linaro.org>
(cherry picked from commit 6b41417d934b2640b7ccf893544d656eea92a2e7)
Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>
(Mjt: fixup in hw/scsi/esp-pci.c due to v8.0.0-1556-g7d5b0d6864
"bulk: Remove pointless QOM casts")
Commit: 5bdc6b957148c96acc3471b22ea6c77f60592e1c
https://github.com/qemu/qemu/commit/5bdc6b957148c96acc3471b22ea6c77f60592e1c
Author: Mark Cave-Ayland <mark.cave-ayland@ilande.co.uk>
Date: 2024-01-20 (Sat, 20 Jan 2024)
Changed paths:
M hw/scsi/esp-pci.c
Log Message:
-----------
hw/scsi/esp-pci: synchronise setting of DMA_STAT_DONE with ESP completion
interrupt
The setting of DMA_STAT_DONE at the end of a DMA transfer can be configured to
generate an interrupt, however the Linux driver manually checks for
DMA_STAT_DONE
being set and if it is, considers that a DMA transfer has completed.
If DMA_STAT_DONE is set but the ESP device isn't indicating an interrupt then
the Linux driver considers this to be a spurious interrupt. However this can
occur in QEMU as there is a delay between the end of DMA transfer where
DMA_STAT_DONE is set, and the ESP device raising its completion interrupt.
This appears to be an incorrect assumption in the Linux driver as the ESP and
PCI DMA interrupt sources are separate (and may not be raised exactly
together), however we can work around this by synchronising the setting of
DMA_STAT_DONE at the end of a DMA transfer with the ESP completion interrupt.
In conjunction with the previous commit Linux is now able to correctly boot
from an am53c974 PCI SCSI device on the hppa C3700 machine without emitting
"iget: checksum invalid" and "Spurious irq, sreg=10" errors.
Signed-off-by: Mark Cave-Ayland <mark.cave-ayland@ilande.co.uk>
Reviewed-by: Guenter Roeck <linux@roeck-us.net>
Tested-by: Guenter Roeck <linux@roeck-us.net>
Message-ID: <20240112131529.515642-4-mark.cave-ayland@ilande.co.uk>
Signed-off-by: Philippe Mathieu-Daudé <philmd@linaro.org>
(cherry picked from commit 1e8e6644e063b20ad391140fae13d00ad7750b33)
Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>
Commit: 7837d7e31de0603aed429b9bfa0615a71ce135e6
https://github.com/qemu/qemu/commit/7837d7e31de0603aed429b9bfa0615a71ce135e6
Author: Mark Cave-Ayland <mark.cave-ayland@ilande.co.uk>
Date: 2024-01-20 (Sat, 20 Jan 2024)
Changed paths:
M hw/scsi/esp-pci.c
Log Message:
-----------
hw/scsi/esp-pci: set DMA_STAT_BCMBLT when BLAST command issued
Even though the BLAST command isn't fully implemented in QEMU, the
DMA_STAT_BCMBLT
bit should be set after the command has been issued to indicate that the command
has completed.
This fixes an issue with the DC390 DOS driver which issues the BLAST command as
part of its normal error recovery routine at startup, and otherwise sits in a
tight loop waiting for DMA_STAT_BCMBLT to be set before continuing.
Signed-off-by: Mark Cave-Ayland <mark.cave-ayland@ilande.co.uk>
Reviewed-by: Guenter Roeck <linux@roeck-us.net>
Tested-by: Guenter Roeck <linux@roeck-us.net>
Message-ID: <20240112131529.515642-5-mark.cave-ayland@ilande.co.uk>
Signed-off-by: Philippe Mathieu-Daudé <philmd@linaro.org>
(cherry picked from commit c2d7de557d19ec76eb83b87b6bf77c8114e2f183)
Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>
Commit: 024e8945fabdffd85f14fca2864ba8f99fb4a835
https://github.com/qemu/qemu/commit/024e8945fabdffd85f14fca2864ba8f99fb4a835
Author: Alex Bennée <alex.bennee@linaro.org>
Date: 2024-01-23 (Tue, 23 Jan 2024)
Changed paths:
M .readthedocs.yml
A docs/requirements.txt
Log Message:
-----------
readthodocs: fully specify a build environment
This is now expected by rtd so I've expanded using their example as
22.04 is one of our supported platforms. I tried to work out if there
was an easy way to re-generate a requirements.txt from our
pythondeps.toml but in the end went for the easier solution.
Cc: <qemu-stable@nongnu.org>
Signed-off-by: Alex Bennée <alex.bennee@linaro.org>
Message-Id: <20231221174200.2693694-1-alex.bennee@linaro.org>
(cherry picked from commit b16a45bc5e0e329a16af8a2e020a6e7044f9afa2)
Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>
Commit: b67924a04838ffb766b57ec2e5815704f46fc454
https://github.com/qemu/qemu/commit/b67924a04838ffb766b57ec2e5815704f46fc454
Author: Paolo Bonzini <pbonzini@redhat.com>
Date: 2024-01-25 (Thu, 25 Jan 2024)
Changed paths:
M accel/tcg/cpu-exec.c
M accel/tcg/tb-maint.c
M accel/tcg/translate-all.c
M include/exec/exec-all.h
Log Message:
-----------
accel/tcg: Revert mapping of PCREL translation block to multiple virtual
addresses
This is causing regressions that have not been analyzed yet. Revert the
change on stable branches.
Cc: qemu-stable@nongnu.org
Cc: Michael Tokarev <mjt@tls.msk.ru>
Related: https://gitlab.com/qemu-project/qemu/-/issues/2092
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>
Commit: 06e11b7589bb6a0d8a004949e829bebcd7a00ec5
https://github.com/qemu/qemu/commit/06e11b7589bb6a0d8a004949e829bebcd7a00ec5
Author: Fiona Ebner <f.ebner@proxmox.com>
Date: 2024-01-25 (Thu, 25 Jan 2024)
Changed paths:
M block/io.c
Log Message:
-----------
block/io: clear BDRV_BLOCK_RECURSE flag after recursing in
bdrv_co_block_status
Using fleecing backup like in [0] on a qcow2 image (with metadata
preallocation) can lead to the following assertion failure:
> bdrv_co_do_block_status: Assertion `!(ret & BDRV_BLOCK_ZERO)' failed.
In the reproducer [0], it happens because the BDRV_BLOCK_RECURSE flag
will be set by the qcow2 driver, so the caller will recursively check
the file child. Then the BDRV_BLOCK_ZERO set too. Later up the call
chain, in bdrv_co_do_block_status() for the snapshot-access driver,
the assertion failure will happen, because both flags are set.
To fix it, clear the recurse flag after the recursive check was done.
In detail:
> #0 qcow2_co_block_status
Returns 0x45 = BDRV_BLOCK_RECURSE | BDRV_BLOCK_DATA |
BDRV_BLOCK_OFFSET_VALID.
> #1 bdrv_co_do_block_status
Because of the data flag, bdrv_co_do_block_status() will now also set
BDRV_BLOCK_ALLOCATED. Because of the recurse flag,
bdrv_co_do_block_status() for the bdrv_file child will be called,
which returns 0x16 = BDRV_BLOCK_ALLOCATED | BDRV_BLOCK_OFFSET_VALID |
BDRV_BLOCK_ZERO. Now the return value inherits the zero flag.
Returns 0x57 = BDRV_BLOCK_RECURSE | BDRV_BLOCK_DATA |
BDRV_BLOCK_OFFSET_VALID | BDRV_BLOCK_ALLOCATED | BDRV_BLOCK_ZERO.
> #2 bdrv_co_common_block_status_above
> #3 bdrv_co_block_status_above
> #4 bdrv_co_block_status
> #5 cbw_co_snapshot_block_status
> #6 bdrv_co_snapshot_block_status
> #7 snapshot_access_co_block_status
> #8 bdrv_co_do_block_status
Return value is propagated all the way up to here, where the assertion
failure happens, because BDRV_BLOCK_RECURSE and BDRV_BLOCK_ZERO are
both set.
> #9 bdrv_co_common_block_status_above
> #10 bdrv_co_block_status_above
> #11 block_copy_block_status
> #12 block_copy_dirty_clusters
> #13 block_copy_common
> #14 block_copy_async_co_entry
> #15 coroutine_trampoline
[0]:
> #!/bin/bash
> rm /tmp/disk.qcow2
> ./qemu-img create /tmp/disk.qcow2 -o preallocation=metadata -f qcow2 1G
> ./qemu-img create /tmp/fleecing.qcow2 -f qcow2 1G
> ./qemu-img create /tmp/backup.qcow2 -f qcow2 1G
> ./qemu-system-x86_64 --qmp stdio \
> --blockdev
> qcow2,node-name=node0,file.driver=file,file.filename=/tmp/disk.qcow2 \
> --blockdev
> qcow2,node-name=node1,file.driver=file,file.filename=/tmp/fleecing.qcow2 \
> --blockdev
> qcow2,node-name=node2,file.driver=file,file.filename=/tmp/backup.qcow2 \
> <<EOF
> {"execute": "qmp_capabilities"}
> {"execute": "blockdev-add", "arguments": { "driver": "copy-before-write",
> "file": "node0", "target": "node1", "node-name": "node3" } }
> {"execute": "blockdev-add", "arguments": { "driver": "snapshot-access",
> "file": "node3", "node-name": "snap0" } }
> {"execute": "blockdev-backup", "arguments": { "device": "snap0", "target":
> "node1", "sync": "full", "job-id": "backup0" } }
> EOF
Signed-off-by: Fiona Ebner <f.ebner@proxmox.com>
Reviewed-by: Vladimir Sementsov-Ogievskiy <vsementsov@yandex-team.ru>
Message-id: 20240116154839.401030-1-f.ebner@proxmox.com
Signed-off-by: Stefan Hajnoczi <stefanha@redhat.com>
(cherry picked from commit 8a9be7992426c8920d4178e7dca59306a18c7a3a)
Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>
Commit: 415f21c723320af3f694efffb6fc47484cc03fb0
https://github.com/qemu/qemu/commit/415f21c723320af3f694efffb6fc47484cc03fb0
Author: Jason Wang <jasowang@redhat.com>
Date: 2024-01-26 (Fri, 26 Jan 2024)
Changed paths:
M hw/net/virtio-net.c
Log Message:
-----------
virtio-net: correctly copy vnet header when flushing TX
When HASH_REPORT is negotiated, the guest_hdr_len might be larger than
the size of the mergeable rx buffer header. Using
virtio_net_hdr_mrg_rxbuf during the header swap might lead a stack
overflow in this case. Fixing this by using virtio_net_hdr_v1_hash
instead.
Reported-by: Xiao Lei <leixiao.nop@zju.edu.cn>
Cc: Yuri Benditovich <yuri.benditovich@daynix.com>
Cc: qemu-stable@nongnu.org
Cc: Mauro Matteo Cascella <mcascell@redhat.com>
Fixes: CVE-2023-6693
Fixes: e22f0603fb2f ("virtio-net: reference implementation of hash report")
Reviewed-by: Michael Tokarev <mjt@tls.msk.ru>
Signed-off-by: Jason Wang <jasowang@redhat.com>
(cherry picked from commit 2220e8189fb94068dbad333228659fbac819abb0)
Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>
Commit: e9eb53c5fed3f60a4ed533d096fd270268f02dc1
https://github.com/qemu/qemu/commit/e9eb53c5fed3f60a4ed533d096fd270268f02dc1
Author: Ari Sundholm <ari@tuxera.com>
Date: 2024-01-26 (Fri, 26 Jan 2024)
Changed paths:
M block/blklogwrites.c
Log Message:
-----------
block/blklogwrites: Fix a bug when logging "write zeroes" operations.
There is a bug in the blklogwrites driver pertaining to logging "write
zeroes" operations, causing log corruption. This can be easily observed
by setting detect-zeroes to something other than "off" for the driver.
The issue is caused by a concurrency bug pertaining to the fact that
"write zeroes" operations have to be logged in two parts: first the log
entry metadata, then the zeroed-out region. While the log entry
metadata is being written by bdrv_co_pwritev(), another operation may
begin in the meanwhile and modify the state of the blklogwrites driver.
This is as intended by the coroutine-driven I/O model in QEMU, of
course.
Unfortunately, this specific scenario is mishandled. A short example:
1. Initially, in the current operation (#1), the current log sector
number in the driver state is only incremented by the number of sectors
taken by the log entry metadata, after which the log entry metadata is
written. The current operation yields.
2. Another operation (#2) may start while the log entry metadata is
being written. It uses the current log position as the start offset for
its log entry. This is in the sector right after the operation #1 log
entry metadata, which is bad!
3. After bdrv_co_pwritev() returns (#1), the current log sector
number is reread from the driver state in order to find out the start
offset for bdrv_co_pwrite_zeroes(). This is an obvious blunder, as the
offset will be the sector right after the (misplaced) operation #2 log
entry, which means that the zeroed-out region begins at the wrong
offset.
4. As a result of the above, the log is corrupt.
Fix this by only reading the driver metadata once, computing the
offsets and sizes in one go (including the optional zeroed-out region)
and setting the log sector number to the appropriate value for the next
operation in line.
Signed-off-by: Ari Sundholm <ari@tuxera.com>
Cc: qemu-stable@nongnu.org
Message-ID: <20240109184646.1128475-1-megari@gmx.com>
Reviewed-by: Kevin Wolf <kwolf@redhat.com>
Signed-off-by: Kevin Wolf <kwolf@redhat.com>
(cherry picked from commit a9c8ea95470c27a8a02062b67f9fa6940e828ab6)
Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>
Commit: 3b53bfd4c8cd17aa3cc73d479e10c7cb88b6b0ad
https://github.com/qemu/qemu/commit/3b53bfd4c8cd17aa3cc73d479e10c7cb88b6b0ad
Author: Stefan Hajnoczi <stefanha@redhat.com>
Date: 2024-01-26 (Fri, 26 Jan 2024)
Changed paths:
M tests/qemu-iotests/iotests.py
Log Message:
-----------
iotests: add filter_qmp_generated_node_ids()
Add a filter function for QMP responses that contain QEMU's
automatically generated node ids. The ids change between runs and must
be masked in the reference output.
The next commit will use this new function.
Signed-off-by: Stefan Hajnoczi <stefanha@redhat.com>
Message-ID: <20240118144823.1497953-2-stefanha@redhat.com>
Reviewed-by: Kevin Wolf <kwolf@redhat.com>
Signed-off-by: Kevin Wolf <kwolf@redhat.com>
(cherry picked from commit da62b507a20510d819bcfbe8f5e573409b954006)
Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>
(Mjt: context fix in tests/qemu-iotests/iotests.py due to
v7.2.0-939-gbcc6777ad6 "iotests: Filter child node information")
Commit: 219cea653e38aac87fa48186a793b6c9bd9a314b
https://github.com/qemu/qemu/commit/219cea653e38aac87fa48186a793b6c9bd9a314b
Author: Stefan Hajnoczi <stefanha@redhat.com>
Date: 2024-01-26 (Fri, 26 Jan 2024)
Changed paths:
M tests/qemu-iotests/141
M tests/qemu-iotests/141.out
Log Message:
-----------
iotests: port 141 to Python for reliable QMP testing
The common.qemu bash functions allow tests to interact with the QMP
monitor of a QEMU process. I spent two days trying to update 141 when
the order of the test output changed, but found it would still fail
occassionally because printf() and QMP events race with synchronous QMP
communication.
I gave up and ported 141 to the existing Python API for QMP tests. The
Python API is less affected by the order in which QEMU prints output
because it does not print all QMP traffic by default.
The next commit changes the order in which QMP messages are received.
Make 141 reliable first.
Cc: Hanna Czenczek <hreitz@redhat.com>
Signed-off-by: Stefan Hajnoczi <stefanha@redhat.com>
Message-ID: <20240118144823.1497953-3-stefanha@redhat.com>
Reviewed-by: Kevin Wolf <kwolf@redhat.com>
Signed-off-by: Kevin Wolf <kwolf@redhat.com>
(cherry picked from commit 9ee2dd4c22a3639c5462b3fc20df60c005c3de64)
Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>
Commit: 8ec90598e922a604c222bdbc6289bed7279dced6
https://github.com/qemu/qemu/commit/8ec90598e922a604c222bdbc6289bed7279dced6
Author: Stefan Hajnoczi <stefanha@redhat.com>
Date: 2024-01-26 (Fri, 26 Jan 2024)
Changed paths:
M monitor/qmp.c
M qapi/qmp-dispatch.c
M tests/qemu-iotests/060.out
M tests/qemu-iotests/071.out
M tests/qemu-iotests/081.out
M tests/qemu-iotests/087.out
M tests/qemu-iotests/108.out
M tests/qemu-iotests/109
M tests/qemu-iotests/109.out
M tests/qemu-iotests/117.out
M tests/qemu-iotests/120.out
M tests/qemu-iotests/127.out
M tests/qemu-iotests/140.out
M tests/qemu-iotests/143.out
M tests/qemu-iotests/156.out
M tests/qemu-iotests/176.out
M tests/qemu-iotests/182.out
M tests/qemu-iotests/183.out
M tests/qemu-iotests/184.out
M tests/qemu-iotests/185
M tests/qemu-iotests/185.out
M tests/qemu-iotests/191.out
M tests/qemu-iotests/195.out
M tests/qemu-iotests/223.out
M tests/qemu-iotests/227.out
M tests/qemu-iotests/247.out
M tests/qemu-iotests/273.out
M tests/qemu-iotests/308
M tests/qemu-iotests/308.out
M tests/qemu-iotests/tests/qsd-jobs.out
Log Message:
-----------
monitor: only run coroutine commands in qemu_aio_context
monitor_qmp_dispatcher_co() runs in the iohandler AioContext that is not
polled during nested event loops. The coroutine currently reschedules
itself in the main loop's qemu_aio_context AioContext, which is polled
during nested event loops. One known problem is that QMP device-add
calls drain_call_rcu(), which temporarily drops the BQL, leading to all
sorts of havoc like other vCPU threads re-entering device emulation code
while another vCPU thread is waiting in device emulation code with
aio_poll().
Paolo Bonzini suggested running non-coroutine QMP handlers in the
iohandler AioContext. This avoids trouble with nested event loops. His
original idea was to move coroutine rescheduling to
monitor_qmp_dispatch(), but I resorted to moving it to qmp_dispatch()
because we don't know if the QMP handler needs to run in coroutine
context in monitor_qmp_dispatch(). monitor_qmp_dispatch() would have
been nicer since it's associated with the monitor implementation and not
as general as qmp_dispatch(), which is also used by qemu-ga.
A number of qemu-iotests need updated .out files because the order of
QMP events vs QMP responses has changed.
Solves Issue #1933.
Cc: qemu-stable@nongnu.org
Fixes: 7bed89958bfbf40df9ca681cefbdca63abdde39d ("device_core: use
drain_call_rcu in in qmp_device_add")
Buglink: https://bugzilla.redhat.com/show_bug.cgi?id=2215192
Buglink: https://bugzilla.redhat.com/show_bug.cgi?id=2214985
Buglink: https://issues.redhat.com/browse/RHEL-17369
Signed-off-by: Stefan Hajnoczi <stefanha@redhat.com>
Message-ID: <20240118144823.1497953-4-stefanha@redhat.com>
Reviewed-by: Kevin Wolf <kwolf@redhat.com>
Tested-by: Fiona Ebner <f.ebner@proxmox.com>
Signed-off-by: Kevin Wolf <kwolf@redhat.com>
(cherry picked from commit effd60c878176bcaf97fa7ce2b12d04bb8ead6f7)
Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>
(Mjt: omit changes to tests missing in 7.2)
Commit: fa020ef10b1448ad4bb998dbdc5917e942363e30
https://github.com/qemu/qemu/commit/fa020ef10b1448ad4bb998dbdc5917e942363e30
Author: Daniel P. Berrangé <berrange@redhat.com>
Date: 2024-01-26 (Fri, 26 Jan 2024)
Changed paths:
M tests/qtest/meson.build
Log Message:
-----------
qtest: bump aspeed_smc-test timeout to 6 minutes
On a loaded system with --enable-debug, this test can take longer than
5 minutes. Raising the timeout to 6 minutes gives greater headroom for
such situations.
Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
[thuth: Increase the timeout to 6 minutes for very loaded systems]
Signed-off-by: Thomas Huth <thuth@redhat.com>
Message-Id: <20231215070357.10888-11-thuth@redhat.com>
Signed-off-by: Alex Bennée <alex.bennee@linaro.org>
(cherry picked from commit e8a12fe31f776c60fec993513cd1b1e66c2b8e29)
Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>
(Mjt: context fixup in tests/qtest/meson.build)
Commit: ecc23c6e9503380c276a303754b6324fc6d4c054
https://github.com/qemu/qemu/commit/ecc23c6e9503380c276a303754b6324fc6d4c054
Author: Max Filippov <jcmvbkbc@gmail.com>
Date: 2024-01-27 (Sat, 27 Jan 2024)
Changed paths:
M target/xtensa/mmu_helper.c
Log Message:
-----------
target/xtensa: fix OOB TLB entry access
r[id]tlb[01], [iw][id]tlb opcodes use TLB way index passed in a register
by the guest. The host uses 3 bits of the index for ITLB indexing and 4
bits for DTLB, but there's only 7 entries in the ITLB array and 10 in
the DTLB array, so a malicious guest may trigger out-of-bound access to
these arrays.
Change split_tlb_entry_spec return type to bool to indicate whether TLB
way passed to it is valid. Change get_tlb_entry to return NULL in case
invalid TLB way is requested. Add assertion to xtensa_tlb_get_entry that
requested TLB way and entry indices are valid. Add checks to the
[rwi]tlb helpers that requested TLB way is valid and return 0 or do
nothing when it's not.
Cc: qemu-stable@nongnu.org
Fixes: b67ea0cd7441 ("target-xtensa: implement memory protection options")
Signed-off-by: Max Filippov <jcmvbkbc@gmail.com>
Reviewed-by: Peter Maydell <peter.maydell@linaro.org>
Message-id: 20231215120307.545381-1-jcmvbkbc@gmail.com
Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
(cherry picked from commit 604927e357c2b292c70826e4ce42574ad126ef32)
Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>
Commit: 0c918cb0abd1ff739a9337bad5a2375d2315a3bb
https://github.com/qemu/qemu/commit/0c918cb0abd1ff739a9337bad5a2375d2315a3bb
Author: Michael Tokarev <mjt@tls.msk.ru>
Date: 2024-01-29 (Mon, 29 Jan 2024)
Changed paths:
M VERSION
Log Message:
-----------
Update version for 7.2.9 release
Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>
Compare: https://github.com/qemu/qemu/compare/71090deb4c84...0c918cb0abd1
| [Prev in Thread] |
Current Thread |
[Next in Thread] |
- [Qemu-commits] [qemu/qemu] a629fe: block: Fix crash when loading snapshot on inactive...,
Alex Bennée <=