Branch: refs/heads/staging-9.2
Home: https://github.com/qemu/qemu
Commit: 4a4426275b0028d1ca76e44c59edba4021eac90c
https://github.com/qemu/qemu/commit/4a4426275b0028d1ca76e44c59edba4021eac90c
Author: Peter Maydell <[email protected]>
Date: 2025-02-25 (Tue, 25 Feb 2025)
Changed paths:
M target/arm/helper.c
Log Message:
-----------
target/arm: Report correct syndrome for UNDEFINED CNTPS_*_EL1 from EL2 and NS
EL1
The access pseudocode for the CNTPS_TVAL_EL1, CNTPS_CTL_EL1 and
CNTPS_CVAL_EL1 secure timer registers says that they are UNDEFINED
from EL2 or NS EL1. We incorrectly return CP_ACCESS_TRAP from the
access function in these cases, which means that we report the wrong
syndrome value to the target EL.
Use CP_ACCESS_TRAP_UNCATEGORIZED, which reports the correct syndrome
value for an UNDEFINED instruction.
Cc: [email protected]
Fixes: b4d3978c2fd ("target-arm: Add the AArch64 view of the Secure physical
timer")
Signed-off-by: Peter Maydell <[email protected]>
Reviewed-by: Alex Bennée <[email protected]>
Reviewed-by: Richard Henderson <[email protected]>
Message-id: [email protected]
(cherry picked from commit b819fd6994243aee6f9613edbbacedce4f511c32)
Signed-off-by: Michael Tokarev <[email protected]>
Commit: 7988e7c6ba18c3cadd0db001d81e0a6536a4ecf3
https://github.com/qemu/qemu/commit/7988e7c6ba18c3cadd0db001d81e0a6536a4ecf3
Author: Peter Maydell <[email protected]>
Date: 2025-02-25 (Tue, 25 Feb 2025)
Changed paths:
M target/arm/helper.c
Log Message:
-----------
target/arm: Report correct syndrome for UNDEFINED AT ops with wrong NSE, NS
R_NYXTL says that these AT insns should be UNDEFINED if they
would operate on an EL lower than EL3 and SCR_EL3.{NSE,NS} is
set to the Reserved {1, 0}. We were incorrectly reporting
them with the wrong syndrome; use CP_ACCESS_TRAP_UNCATEGORIZED
so they are reported as UNDEFINED.
Cc: [email protected]
Fixes: 1acd00ef1410 ("target/arm/helper: Check SCR_EL3.{NSE, NS} encoding for
AT instructions")
Signed-off-by: Peter Maydell <[email protected]>
Reviewed-by: Richard Henderson <[email protected]>
Message-id: [email protected]
(cherry picked from commit 1960d9701ef7ed8d24e98def767bbf05d63e6992)
Signed-off-by: Michael Tokarev <[email protected]>
Commit: 41945c6bbb8744af6b74b2edc1520744fd7c3c53
https://github.com/qemu/qemu/commit/41945c6bbb8744af6b74b2edc1520744fd7c3c53
Author: Peter Maydell <[email protected]>
Date: 2025-02-25 (Tue, 25 Feb 2025)
Changed paths:
M target/arm/helper.c
Log Message:
-----------
target/arm: Report correct syndrome for UNDEFINED S1E2 AT ops at EL3
The pseudocode for AT S1E2R and AT S1E2W says that they should be
UNDEFINED if executed at EL3 when EL2 is not enabled. We were
incorrectly using CP_ACCESS_TRAP and reporting the wrong exception
syndrome as a result. Use CP_ACCESS_TRAP_UNCATEGORIZED.
Cc: [email protected]
Fixes: 2a47df953202e1 ("target-arm: Wire up AArch64 EL2 and EL3 address
translation ops")
Signed-off-by: Peter Maydell <[email protected]>
Reviewed-by: Richard Henderson <[email protected]>
Message-id: [email protected]
(cherry picked from commit ccda792945d650bce4609c8dbce8814a220df1bb)
Signed-off-by: Michael Tokarev <[email protected]>
Commit: a98c7cee174508f9508d77ee6304980d02902cb4
https://github.com/qemu/qemu/commit/a98c7cee174508f9508d77ee6304980d02902cb4
Author: Peter Maydell <[email protected]>
Date: 2025-02-25 (Tue, 25 Feb 2025)
Changed paths:
M target/arm/helper.c
Log Message:
-----------
target/arm: Report correct syndrome for UNDEFINED LOR sysregs when NS=0
The pseudocode for the accessors for the LOR sysregs says they
are UNDEFINED if SCR_EL3.NS is 0. We were reporting the wrong
syndrome value here; use CP_ACCESS_TRAP_UNCATEGORIZED.
Cc: [email protected]
Fixes: 2d7137c10faf ("target/arm: Implement the ARMv8.1-LOR extension")
Signed-off-by: Peter Maydell <[email protected]>
Reviewed-by: Alex Bennée <[email protected]>
Reviewed-by: Richard Henderson <[email protected]>
Message-id: [email protected]
(cherry picked from commit 707d478ed8f2da6f2327e5af780890c1fd9c371a)
Signed-off-by: Michael Tokarev <[email protected]>
Commit: 68b115ddae26960f262d6e00fbde54b75251ab9e
https://github.com/qemu/qemu/commit/68b115ddae26960f262d6e00fbde54b75251ab9e
Author: Peter Maydell <[email protected]>
Date: 2025-02-25 (Tue, 25 Feb 2025)
Changed paths:
M target/arm/cpu.h
M target/arm/helper.c
M target/arm/tcg/op_helper.c
Log Message:
-----------
target/arm: Make CP_ACCESS_TRAPs to AArch32 EL3 be Monitor traps
In system register access pseudocode the common pattern for
AArch32 registers with access traps to EL3 is:
at EL1 and EL2:
if HaveEL(EL3) && !ELUsingAArch32(EL3) && (SCR_EL3.TERR == 1) then
AArch64.AArch32SystemAccessTrap(EL3, 0x03);
elsif HaveEL(EL3) && ELUsingAArch32(EL3) && (SCR.TERR == 1) then
AArch32.TakeMonitorTrapException();
at EL3:
if (PSTATE.M != M32_Monitor) && (SCR.TERR == 1) then
AArch32.TakeMonitorTrapException();
(taking as an example the ERRIDR access pseudocode).
This implements the behaviour of (in this case) SCR.TERR that
"Accesses to the specified registers from modes other than Monitor
mode generate a Monitor Trap exception" and of SCR_EL3.TERR that
"Accesses of the specified Error Record registers at EL2 and EL1
are trapped to EL3, unless the instruction generates a higher
priority exception".
In QEMU we don't implement this pattern correctly in two ways:
* in access_check_cp_reg() we turn the CP_ACCESS_TRAP_EL3 into
an UNDEF, not a trap to Monitor mode
* in the access functions, we check trap bits like SCR.TERR
only when arm_current_el(env) < 3 -- this is correct for
AArch64 EL3, but misses the "trap non-Monitor-mode execution
at EL3 into Monitor mode" case for AArch32 EL3
In this commit we fix the first of these two issues, by
making access_check_cp_reg() handle CP_ACCESS_TRAP_EL3
as a Monitor trap. This is a kind of exception that we haven't
yet implemented(!), so we need a new EXCP_MON_TRAP for it.
This diverges from the pseudocode approach, where every access check
function explicitly checks for "if EL3 is AArch32" and takes a
monitor trap; if we wanted to be closer to the pseudocode we could
add a new CP_ACCESS_TRAP_MONITOR and make all the accessfns use it
when appropriate. But because there are no non-standard cases in the
pseudocode (i.e. where either it raises a Monitor trap that doesn't
correspond to an AArch64 SystemAccessTrap or where it raises a
SystemAccessTrap that doesn't correspond to a Monitor trap), handling
this all in one place seems less likely to result in future bugs
where we forgot again about this special case when writing an
accessor.
(The cc of stable here is because "hw/intc/arm_gicv3_cpuif: Don't
downgrade monitor traps for AArch32 EL3" which is also cc:stable
will implicitly use the new EXCP_MON_TRAP code path.)
Cc: [email protected]
Signed-off-by: Peter Maydell <[email protected]>
Reviewed-by: Alex Bennée <[email protected]>
Reviewed-by: Richard Henderson <[email protected]>
Message-id: [email protected]
(cherry picked from commit 4cf4948651615181c5bc3d0e4a9f5c46be576bb2)
Signed-off-by: Michael Tokarev <[email protected]>
Commit: 7a9fa398560eee55ccb47bade3b83f367d9a44b2
https://github.com/qemu/qemu/commit/7a9fa398560eee55ccb47bade3b83f367d9a44b2
Author: Peter Maydell <[email protected]>
Date: 2025-02-25 (Tue, 25 Feb 2025)
Changed paths:
M hw/intc/arm_gicv3_cpuif.c
Log Message:
-----------
hw/intc/arm_gicv3_cpuif: Don't downgrade monitor traps for AArch32 EL3
In the gicv3_{irq,fiq,irqfiq}_access() functions, there is a check
which downgrades a CP_ACCESS_TRAP_EL3 to CP_ACCESS_TRAP if EL3 is not
AArch64. This has been there since the GIC was first implemented,
but it isn't right: if we are trapping because of SCR.IRQ or SCR.FIQ
then we definitely want to be going to EL3 (doing
AArch32.TakeMonitorTrapException() in pseudocode terms). We might
want to not take a trap at all, but we don't ever want to go to the
default target EL, because that would mean, for instance, taking a
trap to Hyp mode if the trapped access was made from Hyp mode.
(This might have been an attempt to work around our failure to
properly implement Monitor Traps.)
Remove the bogus check.
Cc: [email protected]
Fixes: 359fbe65e01e ("hw/intc/arm_gicv3: Implement GICv3 CPU interface
registers")
Signed-off-by: Peter Maydell <[email protected]>
Reviewed-by: Alex Bennée <[email protected]>
Reviewed-by: Richard Henderson <[email protected]>
Message-id: [email protected]
(cherry picked from commit d04c6c3c000ab3e588a2b91641310aeea89408f7)
Signed-off-by: Michael Tokarev <[email protected]>
Commit: 37600704ddfeca7b98342dc3c298ce014af6b73a
https://github.com/qemu/qemu/commit/37600704ddfeca7b98342dc3c298ce014af6b73a
Author: Peter Maydell <[email protected]>
Date: 2025-02-25 (Tue, 25 Feb 2025)
Changed paths:
M target/arm/cpu.h
M target/arm/debug_helper.c
M target/arm/helper.c
Log Message:
-----------
target/arm: Honour SDCR.TDCC and SCR.TERR in AArch32 EL3 non-Monitor modes
There are not many traps in AArch32 which should trap to Monitor
mode, but these trap bits should trap not just lower ELs to Monitor
mode but also the non-Monitor modes running at EL3 (i.e. Secure
System, Secure Undef, etc).
We get this wrong because the relevant access functions implement the
AArch64-style logic of
if (el < 3 && trap_bit_set) {
return CP_ACCESS_TRAP_EL3;
}
which won't trap the non-Monitor modes at EL3.
Correct this error by using arm_is_el3_or_mon() instead, which
returns true when the CPU is at AArch64 EL3 or AArch32 Monitor mode.
(Since the new callsites are compiled also for the linux-user mode,
we need to provide a dummy implementation for CONFIG_USER_ONLY.)
This affects only:
* trapping of ERRIDR via SCR.TERR
* trapping of the debug channel registers via SDCR.TDCC
* trapping of GICv3 registers via SCR.IRQ and SCR.FIQ
(which we already used arm_is_el3_or_mon() for)
This patch changes the handling of SCR.TERR and SDCR.TDCC. This
patch only changes guest-visible behaviour for "-cpu max" on
the qemu-system-arm binary, because SCR.TERR
and SDCR.TDCC (and indeed the entire SDCR register) only arrived
in Armv8, and the only guest CPU we support which has any v8
features and also starts in AArch32 EL3 is the 32-bit 'max'.
Other uses of CP_ACCESS_TRAP_EL3 don't need changing:
* uses in code paths that can't happen when EL3 is AArch32:
access_trap_aa32s_el1, cpacr_access, cptr_access, nsacr_access
* uses which are in accessfns for AArch64-only registers:
gt_stimer_access, gt_cntpoff_access, access_hxen, access_tpidr2,
access_smpri, access_smprimap, access_lor_ns, access_pauth,
access_mte, access_tfsr_el2, access_scxtnum, access_fgt
* trap bits which exist only in the AArch64 version of the
trap register, not the AArch32 one:
access_tpm, pmreg_access, access_dbgvcr32, access_tdra,
access_tda, access_tdosa (TPM, TDA and TDOSA exist only in
MDCR_EL3, not in SDCR, and we enforce this in sdcr_write())
Cc: [email protected]
Signed-off-by: Peter Maydell <[email protected]>
Reviewed-by: Alex Bennée <[email protected]>
Reviewed-by: Richard Henderson <[email protected]>
Message-id: [email protected]
(cherry picked from commit 4d436fb05c2a1fff7befc815ebcbb04a14977448)
Signed-off-by: Michael Tokarev <[email protected]>
Commit: 3ffbdc3e12269f9269b11f250e45be1a617090aa
https://github.com/qemu/qemu/commit/3ffbdc3e12269f9269b11f250e45be1a617090aa
Author: Peter Maydell <[email protected]>
Date: 2025-02-25 (Tue, 25 Feb 2025)
Changed paths:
M target/arm/tcg/op_helper.c
Log Message:
-----------
target/arm: Correct errors in WFI/WFE trapping
The code for WFI/WFE trapping has several errors:
* it wasn't using arm_sctlr(), so it would look at SCTLR_EL1
even if the CPU was in the EL2&0 translation regime
* it was raising UNDEF, not Monitor Trap, for traps to
AArch32 EL3 because of SCR.{TWE,TWI}
* it was not honouring SCR.{TWE,TWI} when running in
AArch32 at EL3 not in Monitor mode
* it checked SCR.{TWE,TWI} even on v7 CPUs which don't have
those bits
Fix these bugs.
Cc: [email protected]
Fixes: b1eced713d99 ("target-arm: Add WFx instruction trap support")
Signed-off-by: Peter Maydell <[email protected]>
Reviewed-by: Richard Henderson <[email protected]>
Message-id: [email protected]
(cherry picked from commit 2b95a2d01b04afadf510a49ac14b38a59be8c5f5)
Signed-off-by: Michael Tokarev <[email protected]>
Commit: 437999ae814470f4b738b8860a7080498151cae3
https://github.com/qemu/qemu/commit/437999ae814470f4b738b8860a7080498151cae3
Author: Bernhard Beschow <[email protected]>
Date: 2025-02-25 (Tue, 25 Feb 2025)
Changed paths:
M hw/arm/Kconfig
M hw/usb/Kconfig
M hw/usb/meson.build
Log Message:
-----------
Kconfig: Extract CONFIG_USB_CHIPIDEA from CONFIG_IMX
TYPE_CHIPIDEA models an IP block which is also used in TYPE_ZYNQ_MACHINE which
itself is not an IMX device. CONFIG_ZYNQ selects CONFIG_USB_EHCI_SYSBUS while
TYPE_CHIPIDEA is a separate compilation unit, so only works by accident if
CONFIG_IMX is given. Fix that by extracting CONFIG_USB_CHIPIDEA from CONFIG_IMX.
cc: [email protected]
Fixes: 616ec12d0fcc "hw/arm/xilinx_zynq: Fix USB port instantiation"
Signed-off-by: Bernhard Beschow <[email protected]>
Message-id: [email protected]
Reviewed-by: Peter Maydell <[email protected]>
Signed-off-by: Peter Maydell <[email protected]>
(cherry picked from commit 464ce71a963b3dfc290cd59c3d1bfedf11c004df)
(Mjt: context fixup due to missing
v9.2.0-1303-g1b326f278d05 "hw/pci-host/designware: Expose MSI IRQ")
Signed-off-by: Michael Tokarev <[email protected]>
Commit: 4f5adbe6974414aea3ba7c13adf156e824d2f45c
https://github.com/qemu/qemu/commit/4f5adbe6974414aea3ba7c13adf156e824d2f45c
Author: Akihiko Odaki <[email protected]>
Date: 2025-02-25 (Tue, 25 Feb 2025)
Changed paths:
M hw/net/virtio-net.c
Log Message:
-----------
hw/net: Fix NULL dereference with software RSS
When an eBPF program cannot be attached, virtio_net_load_ebpf() returns
false, and virtio_net_device_realize() enters the code path to handle
errors because of this, but it causes NULL dereference because no error
is generated.
Change virtio_net_load_ebpf() to return false only when a fatal error
occurred.
Fixes: b5900dff14e5 ("hw/net: report errors from failing to use eBPF RSS FDs")
Signed-off-by: Akihiko Odaki <[email protected]>
Message-Id: <[email protected]>
Reviewed-by: Michael S. Tsirkin <[email protected]>
Signed-off-by: Michael S. Tsirkin <[email protected]>
(cherry picked from commit bc82af6b0dcb0933e72640851fdd2594f822b23e)
Signed-off-by: Michael Tokarev <[email protected]>
Commit: 1e4ce3dd87cf744f799216f75aacbe9610261fd3
https://github.com/qemu/qemu/commit/1e4ce3dd87cf744f799216f75aacbe9610261fd3
Author: Thomas Huth <[email protected]>
Date: 2025-02-25 (Tue, 25 Feb 2025)
Changed paths:
M hw/i386/pc.c
Log Message:
-----------
hw/i386/pc: Fix crash that occurs when introspecting TYPE_PC_MACHINE machines
QEMU currently crashes when you try to inspect the machines based on
TYPE_PC_MACHINE for their properties:
$ echo '{ "execute": "qmp_capabilities" }
{ "execute": "qom-list-properties","arguments":
{ "typename": "pc-q35-10.0-machine"}}' \
| ./qemu-system-x86_64 -M pc -qmp stdio
{"QMP": {"version": {"qemu": {"micro": 50, "minor": 2, "major": 9},
"package": "v9.2.0-1070-g87e115c122-dirty"}, "capabilities": ["oob"]}}
{"return": {}}
Segmentation fault (core dumped)
This happens because TYPE_PC_MACHINE machines add a machine_init-
done_notifier in their instance_init function - but instance_init
of machines are not only called for machines that are realized,
but also for machines that are introspected, so in this case the
listener is added for a q35 machine that is never realized. But
since there is already a running pc machine, the listener function
is triggered immediately, causing a crash since it was not for the
right machine it was meant for.
Such listener functions must never be installed from an instance_init
function. Let's do it from pc_basic_device_init() instead - this
function is called from the MachineClass->init() function instead,
i.e. guaranteed to be only called once in the lifetime of a QEMU
process.
Resolves: https://gitlab.com/qemu-project/qemu/-/issues/2779
Signed-off-by: Thomas Huth <[email protected]>
Message-Id: <[email protected]>
Reviewed-by: Akihiko Odaki <[email protected]>
Reviewed-by: Michael S. Tsirkin <[email protected]>
Signed-off-by: Michael S. Tsirkin <[email protected]>
(cherry picked from commit de538288e4dac21332cc94ba9727ed8ec8fe5ea1)
Signed-off-by: Michael Tokarev <[email protected]>
Commit: ecaf555439674b26172a2e3c97216962ba54e76c
https://github.com/qemu/qemu/commit/ecaf555439674b26172a2e3c97216962ba54e76c
Author: Thomas Huth <[email protected]>
Date: 2025-02-25 (Tue, 25 Feb 2025)
Changed paths:
M hw/i386/microvm.c
Log Message:
-----------
hw/i386/microvm: Fix crash that occurs when introspecting the microvm machine
QEMU currently crashes when you try to inspect the properties of the
microvm machine:
$ echo '{ "execute": "qmp_capabilities" }
{ "execute": "qom-list-properties","arguments":
{ "typename": "microvm-machine"}}' | \
./qemu-system-x86_64 -qmp stdio
{"QMP": {"version": {"qemu": {"micro": 50, "minor": 2, "major": 9},
"package": "v9.2.0-1072-g60af367187-dirty"}, "capabilities": ["oob"]}}
{"return": {}}
qemu-system-x86_64: ../qemu/hw/i386/acpi-microvm.c:250:
void acpi_setup_microvm(MicrovmMachineState *):
Assertion `x86ms->fw_cfg' failed.
Aborted (core dumped)
This happens because the microvm machine adds a machine_done (and a
powerdown_req) notifier in their instance_init function - however, the
instance_init of machines are not only called for machines that are
realized, but also for machines that are introspected, so in this case
the listener is added for a microvm machine that is never realized. And
since there is already a running machine, the listener function is
triggered immediately, causing a crash since it was not for the right
machine it was meant for.
Such listener functions must never be installed from an instance_init
function. Let's do it from microvm_machine_state_init() instead - this
function is the MachineClass->init() function instead, i.e. guaranteed
to be only called once in the lifetime of a QEMU process.
Since the microvm_machine_done() and microvm_powerdown_req() were
defined quite late in the microvm.c file, we have to move them now
also earlier, so that we can get their function pointers from
microvm_machine_state_init() without having to introduce a separate
prototype for those functions earlier.
Reviewed-by: Sergio Lopez <[email protected]>
Signed-off-by: Thomas Huth <[email protected]>
Message-Id: <[email protected]>
Reviewed-by: Akihiko Odaki <[email protected]>
Reviewed-by: Michael S. Tsirkin <[email protected]>
Signed-off-by: Michael S. Tsirkin <[email protected]>
(cherry picked from commit 38ef383073b8ee59d598643160f206a19a46237f)
Signed-off-by: Michael Tokarev <[email protected]>
Commit: 84858471e6c0580424c48f40a0fef674c722d8ab
https://github.com/qemu/qemu/commit/84858471e6c0580424c48f40a0fef674c722d8ab
Author: Sairaj Kodilkar <[email protected]>
Date: 2025-02-25 (Tue, 25 Feb 2025)
Changed paths:
M hw/i386/amd_iommu.c
Log Message:
-----------
amd_iommu: Use correct DTE field for interrupt passthrough
Interrupt passthrough is determine by the bits 191,190,187-184.
These bits are part of the 3rd quad word (i.e. index 2) in DTE. Hence
replace dte[3] by dte[2].
Fixes: b44159fe0 ("x86_iommu/amd: Add interrupt remap support when VAPIC is not
enabled")
Signed-off-by: Sairaj Kodilkar <[email protected]>
Reviewed-by: Vasant Hegde <[email protected]>
Message-Id: <[email protected]>
Reviewed-by: Michael S. Tsirkin <[email protected]>
Signed-off-by: Michael S. Tsirkin <[email protected]>
(cherry picked from commit 63dc0b8647391b372f3bb38ff1066f6b4a5e6ea1)
Signed-off-by: Michael Tokarev <[email protected]>
Commit: d1b8423fb804c29a3937e613decf205e70768b83
https://github.com/qemu/qemu/commit/d1b8423fb804c29a3937e613decf205e70768b83
Author: Sairaj Kodilkar <[email protected]>
Date: 2025-02-25 (Tue, 25 Feb 2025)
Changed paths:
M hw/i386/amd_iommu.c
M hw/i386/amd_iommu.h
Log Message:
-----------
amd_iommu: Use correct bitmask to set capability BAR
AMD IOMMU provides the base address of control registers through
IVRS table and PCI capability. Since this base address is of 64 bit,
use 32 bits mask (instead of 16 bits) to set BAR low and high.
Fixes: d29a09ca68 ("hw/i386: Introduce AMD IOMMU")
Signed-off-by: Sairaj Kodilkar <[email protected]>
Reviewed-by: Vasant Hegde <[email protected]>
Message-Id: <[email protected]>
Reviewed-by: Michael S. Tsirkin <[email protected]>
Signed-off-by: Michael S. Tsirkin <[email protected]>
(cherry picked from commit 3684717b7407cc395dc9bf522e193dbc85293dee)
Signed-off-by: Michael Tokarev <[email protected]>
Commit: 9b878bd927fe32d73ef2d468a2bd154ff523abb6
https://github.com/qemu/qemu/commit/9b878bd927fe32d73ef2d468a2bd154ff523abb6
Author: Stefano Garzarella <[email protected]>
Date: 2025-02-25 (Tue, 25 Feb 2025)
Changed paths:
M backends/cryptodev-vhost.c
Log Message:
-----------
cryptodev/vhost: allocate CryptoDevBackendVhost using g_mem0()
The function `vhost_dev_init()` expects the `struct vhost_dev`
(passed as a parameter) to be fully initialized. This is important
because some parts of the code check whether `vhost_dev->config_ops`
is NULL to determine if it has been set (e.g. later via
`vhost_dev_set_config_notifier`).
To ensure this initialization, it’s better to allocate the entire
`CryptoDevBackendVhost` structure (which includes `vhost_dev`) using
`g_mem0()`, following the same approach used for other vhost devices,
such as in `vhost_net_init()`.
Fixes: 042cea274c ("cryptodev: add vhost-user as a new cryptodev backend")
Cc: [email protected]
Reported-by: [email protected]
Signed-off-by: Stefano Garzarella <[email protected]>
Message-Id: <[email protected]>
Reviewed-by: Michael S. Tsirkin <[email protected]>
Signed-off-by: Michael S. Tsirkin <[email protected]>
(cherry picked from commit 83cb18ac4500f3a14067b19408705068647cb0c5)
Signed-off-by: Michael Tokarev <[email protected]>
Commit: 86d94725aedfe6da0d8b9067eb37deef06cdd7ab
https://github.com/qemu/qemu/commit/86d94725aedfe6da0d8b9067eb37deef06cdd7ab
Author: Konstantin Shkolnyy <[email protected]>
Date: 2025-02-25 (Tue, 25 Feb 2025)
Changed paths:
M hw/virtio/vhost-shadow-virtqueue.c
Log Message:
-----------
vdpa: Fix endian bugs in shadow virtqueue
VDPA didn't work on a big-endian machine due to missing/incorrect
CPU<->LE data format conversions.
Signed-off-by: Konstantin Shkolnyy <[email protected]>
Message-Id: <[email protected]>
Fixes: 10857ec0ad ("vhost: Add VhostShadowVirtqueue")
Acked-by: Eugenio Pérez <[email protected]>
Tested-by: Lei Yang <[email protected]>
Reviewed-by: Michael S. Tsirkin <[email protected]>
Signed-off-by: Michael S. Tsirkin <[email protected]>
(cherry picked from commit 50e9754149066dc91f58405d3378b589098cb408)
Signed-off-by: Michael Tokarev <[email protected]>
Commit: de563bb593dc98a53df2ba9be1783d0168eb442c
https://github.com/qemu/qemu/commit/de563bb593dc98a53df2ba9be1783d0168eb442c
Author: Alexander Graf <[email protected]>
Date: 2025-02-25 (Tue, 25 Feb 2025)
Changed paths:
M hw/virtio/virtio-nsm.c
Log Message:
-----------
hw/virtio/virtio-nsm: Respond with correct length
When we return a response packet from NSM, we need to indicate its
length according to the content of the response. Prior to this patch, we
returned the length of the source buffer, which may confuse guest code
that relies on the response size.
Fix it by returning the response payload size instead.
Fixes: bb154e3e0cc715 ("device/virtio-nsm: Support for Nitro Secure Module
device")
Reported-by: Vikrant Garg <[email protected]>
Signed-off-by: Alexander Graf <[email protected]>
Message-Id: <[email protected]>
Reviewed-by: Dorjoy Chowdhury <[email protected]>
Fixes: bb154e3e0cc715 ("device/virtio-nsm: Support for Nitro Secure Module
device")<br>
Reported-by: Vikrant Garg <[email protected]>
Signed-off-by: Alexander Graf <[email protected]>
Reviewed-by: Philippe Mathieu-Daudé <[email protected]>
Tested-by: Vikrant Garg <[email protected]>
Reviewed-by: Michael S. Tsirkin <[email protected]>
Signed-off-by: Michael S. Tsirkin <[email protected]>
(cherry picked from commit 131fe64e63c88ec52c45a5946a478c0edeb31b78)
Signed-off-by: Michael Tokarev <[email protected]>
Commit: 5d9dfe1f65c6f964ad96b1f086a78ec78d266ae4
https://github.com/qemu/qemu/commit/5d9dfe1f65c6f964ad96b1f086a78ec78d266ae4
Author: Matias Ezequiel Vara Larsen <[email protected]>
Date: 2025-02-25 (Tue, 25 Feb 2025)
Changed paths:
M hw/virtio/vhost-user-snd.c
Log Message:
-----------
vhost-user-snd: correct the calculation of config_size
Use virtio_get_config_size() rather than sizeof(struct
virtio_snd_config) for the config_size in the vhost-user-snd frontend.
The frontend shall rely on device features for the size of the device
configuration space. The presence of `controls` in the config space
depends on VIRTIO_SND_F_CTLS according to the specification (v1.3):
`
5.14.4 Device Configuration Layout
...
controls
(driver-read-only) indicates a total number of all available control
elements if VIRTIO_SND_F_CTLS has been negotiated.
`
This fixes an issue introduced by commit ab0c7fb2 ("linux-headers:
update to current kvm/next") in which the optional field `controls` is
added to the virtio_snd_config structure. This breaks vhost-user-device
backends that do not implement the `controls` field.
Fixes: ab0c7fb22b ("linux-headers: update to current kvm/next")
Resolves: https://gitlab.com/qemu-project/qemu/-/issues/2805
Reviewed-by: Philippe Mathieu-Daudé <[email protected]>
Suggested-by: Stefano Garzarella <[email protected]>
Signed-off-by: Matias Ezequiel Vara Larsen <[email protected]>
Message-Id: <[email protected]>
Cc: [email protected]
Reviewed-by: Stefano Garzarella <[email protected]>
Reviewed-by: Dorinda Bassey <[email protected]>
Reviewed-by: Michael S. Tsirkin <[email protected]>
Signed-off-by: Michael S. Tsirkin <[email protected]>
(cherry picked from commit e87b6efb11be9f5ff213461f5ecdbae47d9402b9)
(Mjt: context fix for 9.2)
Signed-off-by: Michael Tokarev <[email protected]>
Commit: a8ec7b32cf4258176f4612df2a14dafc08bfd640
https://github.com/qemu/qemu/commit/a8ec7b32cf4258176f4612df2a14dafc08bfd640
Author: Bibo Mao <[email protected]>
Date: 2025-03-02 (Sun, 02 Mar 2025)
Changed paths:
M target/loongarch/gdbstub.c
Log Message:
-----------
target/loongarch/gdbstub: Fix gdbstub incorrectly handling some registers
Write operation with R32 (orig_a0) and R34 (CSR_BADV) is discarded on
gdbstub implementation for LoongArch system. And return value should
be register size rather than 0, since it is used to calculate offset of
next register such as R33 (PC) in function handle_write_all_regs().
Cc: [email protected]
Fixes: ca61e75071c6 ("target/loongarch: Add gdb support.")
Signed-off-by: Bibo Mao <[email protected]>
Reviewed-by: Bibo Mao <[email protected]>
(cherry picked from commit 7bd4eaa847fcdbc4505d9ab95dafa21791d8302a)
Signed-off-by: Michael Tokarev <[email protected]>
Commit: c539cb6fda18bf2f0df5b733a1b2ea6acc7d6909
https://github.com/qemu/qemu/commit/c539cb6fda18bf2f0df5b733a1b2ea6acc7d6909
Author: Paolo Bonzini <[email protected]>
Date: 2025-03-04 (Tue, 04 Mar 2025)
Changed paths:
M system/physmem.c
Log Message:
-----------
physmem: replace assertion with error
It is possible to start QEMU with a confidential-guest-support object
even in TCG mode. While there is already a check in qemu_machine_creation_done:
if (machine->cgs && !machine->cgs->ready) {
error_setg(errp, "accelerator does not support confidential guest %s",
object_get_typename(OBJECT(machine->cgs)));
exit(1);
}
the creation of RAMBlocks happens earlier, in qemu_init_board(), if
the command line does not override the default memory backend with
-M memdev. Then the RAMBlock will try to use guest_memfd (because
machine_require_guest_memfd correctly returns true; at least correctly
according to the current implementation) and trigger the assertion
failure for kvm_enabled(). This happend with a command line as
simple as the following:
qemu-system-x86_64 -m 512 -nographic -object
sev-snp-guest,reduced-phys-bits=48,id=sev0 \
-M q35,kernel-irqchip=split,confidential-guest-support=sev0
qemu-system-x86_64: ../system/physmem.c:1871: ram_block_add: Assertion
`kvm_enabled()' failed.
Cc: Xiaoyao Li <[email protected]>
Cc: [email protected]
Signed-off-by: Paolo Bonzini <[email protected]>
Reviewed-by: Daniel P. Berrangé <[email protected]>
Reviewed-by: David Hildenbrand <[email protected]>
Reviewed-by: Pankaj Gupta <[email protected]>
Reviewed-by: Xiaoyao Li <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Paolo Bonzini <[email protected]>
(cherry picked from commit 6debfb2cb1795427d2dc6a741c7430a233c76695)
Signed-off-by: Michael Tokarev <[email protected]>
Commit: d04eb3275ba463fb06f85e8619813e67544f2d73
https://github.com/qemu/qemu/commit/d04eb3275ba463fb06f85e8619813e67544f2d73
Author: Joelle van Dyne <[email protected]>
Date: 2025-03-04 (Tue, 04 Mar 2025)
Changed paths:
M target/arm/hvf/hvf.c
Log Message:
-----------
target/arm/hvf: Disable SME feature
macOS 15.2's Hypervisor.framework exposes SME feature on M4 Macs.
However, QEMU's hvf accelerator code does not properly support it
yet, causing QEMU to fail to start when hvf accelerator is used on
these systems, with the error message:
qemu-aarch64-softmmu: cannot disable sme4224
All SME vector lengths are disabled.
With SME enabled, at least one vector length must be enabled.
Ideally we would have SME support on these hosts; however, until that
point, we must suppress the SME feature in the ID registers, so that
users can at least run non-SME guests.
Cc: [email protected]
Resolves: https://gitlab.com/qemu-project/qemu/-/issues/2665
Signed-off-by: Joelle van Dyne <[email protected]>
Message-id: [email protected]
Reviewed-by: Peter Maydell <[email protected]>
[PMM: expanded commit message, comment]
Signed-off-by: Peter Maydell <[email protected]>
(cherry picked from commit fd207677a83087454b8afef31651985a1df0d2dd)
Signed-off-by: Michael Tokarev <[email protected]>
Commit: 30ad85ed7f61dc9f37ee8a64e3de9095dbcc498b
https://github.com/qemu/qemu/commit/30ad85ed7f61dc9f37ee8a64e3de9095dbcc498b
Author: Joelle van Dyne <[email protected]>
Date: 2025-03-04 (Tue, 04 Mar 2025)
Changed paths:
M target/arm/hvf/hvf.c
Log Message:
-----------
target/arm/hvf: sign extend the data for a load operation when SSE=1
In the syndrome value for a data abort, bit 21 is SSE, which is
set to indicate that the abort was on a sign-extending load. When
we handle the data abort from the guest via address_space_read(),
we forgot to handle this and so would return the wrong value if
the guest did a sign-extending load to an MMIO region. Add the
sign-extension of the returned data.
Cc: [email protected]
Signed-off-by: Joelle van Dyne <[email protected]>
Message-id: [email protected]
[PMM: Drop an unnecessary check on 'len'; expand commit message]
Reviewed-by: Peter Maydell <[email protected]>
Signed-off-by: Peter Maydell <[email protected]>
(cherry picked from commit 12c365315ab25d364cff24dfeea8d7ff1e752b9f)
Signed-off-by: Michael Tokarev <[email protected]>
Commit: 160f4a35d94031641bb409681093ad3099da166f
https://github.com/qemu/qemu/commit/160f4a35d94031641bb409681093ad3099da166f
Author: Max Chou <[email protected]>
Date: 2025-03-06 (Thu, 06 Mar 2025)
Changed paths:
M target/riscv/vector_helper.c
Log Message:
-----------
target/riscv: rvv: Fix unexpected behavior of vector reduction instructions
when vl is 0
According to the Vector Reduction Operations section in the RISC-V "V"
Vector Extension spec,
"If vl=0, no operation is performed and the destination register is not
updated."
The vd should be updated when vl is larger than 0.
Fixes: fe5c9ab1fc ("target/riscv: vector single-width integer reduction
instructions")
Fixes: f714361ed7 ("target/riscv: rvv-1.0: implement vstart CSR")
Signed-off-by: Max Chou <[email protected]>
Reviewed-by: Daniel Henrique Barboza <[email protected]>
Message-ID: <[email protected]>
Signed-off-by: Alistair Francis <[email protected]>
(cherry picked from commit ffd455963f230c7dc04965609d6675da687a5a78)
Signed-off-by: Michael Tokarev <[email protected]>
Commit: b0ee2b8abe59bf05e52737f0827c410e1bec3011
https://github.com/qemu/qemu/commit/b0ee2b8abe59bf05e52737f0827c410e1bec3011
Author: Max Chou <[email protected]>
Date: 2025-03-06 (Thu, 06 Mar 2025)
Changed paths:
M target/riscv/cpu.c
Log Message:
-----------
target/riscv: rvv: Fix incorrect vlen comparison in prop_vlen_set
In prop_vlen_set function, there is an incorrect comparison between
vlen(bit) and vlenb(byte).
This will cause unexpected error when user applies the `vlen=1024` cpu
option with a vendor predefined cpu type that the default vlen is
1024(vlenb=128).
Fixes: 4f6d036ccc ("target/riscv/cpu.c: remove cpu->cfg.vlen")
Signed-off-by: Max Chou <[email protected]>
Reviewed-by: Daniel Henrique Barboza <[email protected]>
Message-ID: <[email protected]>
Signed-off-by: Alistair Francis <[email protected]>
(cherry picked from commit bf3adf93f16730ca5aaa6c26cf969e64eeff6e7b)
Signed-off-by: Michael Tokarev <[email protected]>
Commit: 092e937184ee5c4c380984678e678719a6d6b5ef
https://github.com/qemu/qemu/commit/092e937184ee5c4c380984678e678719a6d6b5ef
Author: Daniel Henrique Barboza <[email protected]>
Date: 2025-03-06 (Thu, 06 Mar 2025)
Changed paths:
M target/riscv/debug.c
Log Message:
-----------
target/riscv/debug.c: use wp size = 4 for 32-bit CPUs
The mcontrol select bit (19) is always zero, meaning our triggers will
always match virtual addresses. In this condition, if the user does not
specify a size for the trigger, the access size defaults to XLEN.
At this moment we're using def_size = 8 regardless of CPU XLEN. Use
def_size = 4 in case we're running 32 bits.
Fixes: 95799e36c1 ("target/riscv: Add initial support for the Sdtrig extension")
Signed-off-by: Daniel Henrique Barboza <[email protected]>
Reviewed-by: Alistair Francis <[email protected]>
Reviewed-by: Philippe Mathieu-Daudé <[email protected]>
Message-ID: <[email protected]>
Signed-off-by: Alistair Francis <[email protected]>
(cherry picked from commit 3fba76e61caa46329afc399b3ecaaba70c8b0a4e)
Signed-off-by: Michael Tokarev <[email protected]>
Commit: c61a709d373fa0697f25a2262eba7905121dfdea
https://github.com/qemu/qemu/commit/c61a709d373fa0697f25a2262eba7905121dfdea
Author: Daniel Henrique Barboza <[email protected]>
Date: 2025-03-06 (Thu, 06 Mar 2025)
Changed paths:
M target/riscv/cpu_helper.c
Log Message:
-----------
target/riscv: throw debug exception before page fault
In the RISC-V privileged ISA section 3.1.15 table 15, it is determined
that a debug exception that is triggered from a load/store has a higher
priority than a possible fault that this access might trigger.
This is not the case ATM as shown in [1]. Adding a breakpoint in an
address that deliberately will fault is causing a load page fault
instead of a debug exception. The reason is that we're throwing in the
page fault as soon as the fault occurs (end of riscv_cpu_tlb_fill(),
raise_mmu_exception()), not allowing the installed watchpoints to
trigger.
Call cpu_check_watchpoint() in the page fault path to search and execute
any watchpoints that might exist for the address, never returning back
to the fault path. If no watchpoints are found cpu_check_watchpoint()
will return and we'll fall-through the regular path to
raise_mmu_exception().
[1] https://gitlab.com/qemu-project/qemu/-/issues/2627
Resolves: https://gitlab.com/qemu-project/qemu/-/issues/2627
Signed-off-by: Daniel Henrique Barboza <[email protected]>
Reviewed-by: Alistair Francis <[email protected]>
Reviewed-by: Richard Henderson <[email protected]>
Message-ID: <[email protected]>
Signed-off-by: Alistair Francis <[email protected]>
(cherry picked from commit c86edc547692d812d1dcc04220c38310be2c00c3)
Signed-off-by: Michael Tokarev <[email protected]>
Commit: bdd0c0619af785ce617eaab0ab38b6edd1470149
https://github.com/qemu/qemu/commit/bdd0c0619af785ce617eaab0ab38b6edd1470149
Author: Rodrigo Dias Correa <[email protected]>
Date: 2025-03-06 (Thu, 06 Mar 2025)
Changed paths:
M hw/rtc/goldfish_rtc.c
Log Message:
-----------
goldfish_rtc: Fix tick_offset migration
Instead of migrating the raw tick_offset, goldfish_rtc migrates a
recalculated value based on QEMU_CLOCK_VIRTUAL. As QEMU_CLOCK_VIRTUAL
stands still across a save-and-restore cycle, the guest RTC becomes out
of sync with the host RTC when the VM is restored.
As described in the bug description, it looks like this calculation was
copied from pl031 RTC, which had its tick_offset migration fixed by
Commit 032cfe6a79c8 ("pl031: Correctly migrate state when using -rtc
clock=host").
Migrate the tick_offset directly, adding it as a version-dependent field
to VMState. Keep the old behavior when migrating from previous versions.
Resolves: https://gitlab.com/qemu-project/qemu/-/issues/2033
Signed-off-by: Rodrigo Dias Correa <[email protected]>
Reviewed-by: Alistair Francis <[email protected]>
Message-ID: <[email protected]>
Signed-off-by: Alistair Francis <[email protected]>
(cherry picked from commit 3521f9cadc29c7d68b73b325ddb46a7acebf6212)
Signed-off-by: Michael Tokarev <[email protected]>
Commit: 151cd89087816e0c1b3cbf55afc47b0dd463089a
https://github.com/qemu/qemu/commit/151cd89087816e0c1b3cbf55afc47b0dd463089a
Author: Denis Rastyogin <[email protected]>
Date: 2025-03-07 (Fri, 07 Mar 2025)
Changed paths:
M block/qed.c
Log Message:
-----------
block/qed: fix use-after-free by nullifying timer pointer after free
This error was discovered by fuzzing qemu-img.
In the QED block driver, the need_check_timer timer is freed in
bdrv_qed_detach_aio_context, but the pointer to the timer is not
set to NULL. This can lead to a use-after-free scenario
in bdrv_qed_drain_begin().
The need_check_timer pointer is set to NULL after freeing the timer.
Which helps catch this condition when checking in bdrv_qed_drain_begin().
Closes: https://gitlab.com/qemu-project/qemu/-/issues/2852
Signed-off-by: Denis Rastyogin <[email protected]>
Message-ID: <[email protected]>
Signed-off-by: Stefan Hajnoczi <[email protected]>
(cherry picked from commit 2ad638a3d160923ef3dbf87c73944e6e44bdc724)
Signed-off-by: Michael Tokarev <[email protected]>
Commit: d581dce58da370ba6ded984f4d89b1e0c9807de0
https://github.com/qemu/qemu/commit/d581dce58da370ba6ded984f4d89b1e0c9807de0
Author: Markus Armbruster <[email protected]>
Date: 2025-03-07 (Fri, 07 Mar 2025)
Changed paths:
M docs/about/build-platforms.rst
Log Message:
-----------
docs/about/build-platforms: Correct minimum supported Python version
Fixes: ca056f4499c2 (Python: Drop support for Python 3.7)
Signed-off-by: Markus Armbruster <[email protected]>
Message-ID: <[email protected]>
Reviewed-by: Daniel P. Berrangé <[email protected]>
(cherry picked from commit 87c8b4fc3c1c89ec52540bfb74f9b0518f247323)
Signed-off-by: Michael Tokarev <[email protected]>
Commit: 5d7226bdeef82e44fd76f18119ac35564a009a1a
https://github.com/qemu/qemu/commit/5d7226bdeef82e44fd76f18119ac35564a009a1a
Author: Patrick Venture <[email protected]>
Date: 2025-03-09 (Sun, 09 Mar 2025)
Changed paths:
M hw/gpio/npcm7xx_gpio.c
Log Message:
-----------
hw/gpio: npcm7xx: fixup out-of-bounds access
The reg isn't validated to be a possible register before
it's dereferenced for one case. The mmio space registered
for the gpio device is 4KiB but there aren't that many
registers in the struct.
Cc: [email protected]
Fixes: 526dbbe0874 ("hw/gpio: Add GPIO model for Nuvoton NPCM7xx")
Signed-off-by: Patrick Venture <[email protected]>
Reviewed-by: Philippe Mathieu-Daudé <[email protected]>
Message-id: [email protected]
Signed-off-by: Peter Maydell <[email protected]>
(cherry picked from commit 3b2e22c0bbe2ce07123d93961d52f17644562cd7)
Signed-off-by: Michael Tokarev <[email protected]>
Commit: 9a78e4f2f79407e280019cc11629cffe015c566a
https://github.com/qemu/qemu/commit/9a78e4f2f79407e280019cc11629cffe015c566a
Author: Peter Maydell <[email protected]>
Date: 2025-03-09 (Sun, 09 Mar 2025)
Changed paths:
M target/arm/helper.c
Log Message:
-----------
target/arm: Apply correct timer offset when calculating deadlines
When we are calculating timer deadlines, the correct definition of
whether or not to apply an offset to the physical count is described
in the Arm ARM DDI4087 rev L.a section D12.2.4.1. This is different
from when the offset should be applied for a direct read of the
counter sysreg.
We got this right for the EL1 physical timer and for the EL1 virtual
timer, but got all the rest wrong: they should be using a zero offset
always.
Factor the offset calculation out into a function that has a comment
documenting exactly which offset it is calculating and which gets the
HYP, SEC, and HYPVIRT cases right.
Cc: [email protected]
Signed-off-by: Peter Maydell <[email protected]>
Reviewed-by: Alex Bennée <[email protected]>
Message-id: [email protected]
(cherry picked from commit db6c2192839ee0282d38f6f6666a87e0629fcd13)
Signed-off-by: Michael Tokarev <[email protected]>
Commit: 9cc747b7763a62bd3fce3a05ea0e24d081794a6b
https://github.com/qemu/qemu/commit/9cc747b7763a62bd3fce3a05ea0e24d081794a6b
Author: Peter Maydell <[email protected]>
Date: 2025-03-09 (Sun, 09 Mar 2025)
Changed paths:
M target/arm/helper.c
Log Message:
-----------
target/arm: Don't apply CNTVOFF_EL2 for EL2_VIRT timer
The CNTVOFF_EL2 offset register should only be applied for accessses
to CNTVCT_EL0 and for the EL1 virtual timer (CNTV_*). We were
incorrectly applying it for the EL2 virtual timer (CNTHV_*).
Cc: [email protected]
Signed-off-by: Peter Maydell <[email protected]>
Reviewed-by: Alex Bennée <[email protected]>
Message-id: [email protected]
(cherry picked from commit 5709038aa8b4d58b8c201ed53c327074173a35c6)
Signed-off-by: Michael Tokarev <[email protected]>
Commit: 40833041ccaeabbfd1aa57f172a4d3f1dd002b91
https://github.com/qemu/qemu/commit/40833041ccaeabbfd1aa57f172a4d3f1dd002b91
Author: Peter Maydell <[email protected]>
Date: 2025-03-09 (Sun, 09 Mar 2025)
Changed paths:
M target/arm/helper.c
Log Message:
-----------
target/arm: Make CNTPS_* UNDEF from Secure EL1 when Secure EL2 is enabled
When we added Secure EL2 support, we missed that this needs an update
to the access code for the EL3 physical timer registers. These are
supposed to UNDEF from Secure EL1 when Secure EL2 is enabled.
(Note for stable backporting: for backports to branches where
CP_ACCESS_UNDEFINED is not defined, the old name to use instead
is CP_ACCESS_TRAP_UNCATEGORIZED.)
Cc: [email protected]
Signed-off-by: Peter Maydell <[email protected]>
Reviewed-by: Alex Bennée <[email protected]>
Message-id: [email protected]
(cherry picked from commit bdd641541fbef0a27bf9f60e7eba6f8a31d4706c)
Signed-off-by: Michael Tokarev <[email protected]>
Commit: db4e3b31a861068f8b881c5accb1bf7f52c5cd75
https://github.com/qemu/qemu/commit/db4e3b31a861068f8b881c5accb1bf7f52c5cd75
Author: Peter Maydell <[email protected]>
Date: 2025-03-09 (Sun, 09 Mar 2025)
Changed paths:
M target/arm/helper.c
Log Message:
-----------
target/arm: Always apply CNTVOFF_EL2 for CNTV_TVAL_EL02 accesses
Currently we handle CNTV_TVAL_EL02 by calling gt_tval_read() for the
EL1 virt timer. This is almost correct, but the underlying
CNTV_TVAL_EL0 register behaves slightly differently. CNTV_TVAL_EL02
always applies the CNTVOFF_EL2 offset; CNTV_TVAL_EL0 doesn't do so if
we're at EL2 and HCR_EL2.E2H is 1.
We were getting this wrong, because we ended up in
gt_virt_cnt_offset() and did the E2H check.
Factor out the tval read/write calculation from the selection of the
offset, so that we can special case gt_virt_tval_read() and
gt_virt_tval_write() to unconditionally pass CNTVOFF_EL2.
Cc: [email protected]
Signed-off-by: Peter Maydell <[email protected]>
Reviewed-by: Alex Bennée <[email protected]>
Message-id: [email protected]
(cherry picked from commit 4aecd4b442d7abb4355896d878ffc9b028625b01)
Signed-off-by: Michael Tokarev <[email protected]>
Commit: b274b4a5f75553b4708c1bee1b6b495be39a8d10
https://github.com/qemu/qemu/commit/b274b4a5f75553b4708c1bee1b6b495be39a8d10
Author: Peter Maydell <[email protected]>
Date: 2025-03-09 (Sun, 09 Mar 2025)
Changed paths:
M target/arm/helper.c
M target/arm/internals.h
M target/arm/tcg/op_helper.c
Log Message:
-----------
target/arm: Refactor handling of timer offset for direct register accesses
When reading or writing the timer registers, sometimes we need to
apply one of the timer offsets. Specifically, this happens for
direct reads of the counter registers CNTPCT_EL0 and CNTVCT_EL0 (and
their self-synchronized variants CNTVCTSS_EL0 and CNTPCTSS_EL0). It
also applies for direct reads and writes of the CNT*_TVAL_EL*
registers that provide the 32-bit downcounting view of each timer.
We currently do this with duplicated code in gt_tval_read() and
gt_tval_write() and a special-case in gt_virt_cnt_read() and
gt_cnt_read(). Refactor this so that we handle it all in a single
function gt_direct_access_timer_offset(), to parallel how we handle
the offset for indirect accesses.
The call in the WFIT helper previously to gt_virt_cnt_offset() is
now to gt_direct_access_timer_offset(); this is the correct
behaviour, but it's not immediately obvious that it shouldn't be
considered an indirect access, so we add an explanatory comment.
This commit should make no behavioural changes.
(Cc to stable because the following bugfix commit will
depend on this one.)
Cc: [email protected]
Signed-off-by: Peter Maydell <[email protected]>
Reviewed-by: Alex Bennée <[email protected]>
Message-id: [email protected]
(cherry picked from commit 02c648a0a103a1a7b2c077ec5a81da9907f45544)
(Mjt: context fix in target/arm/internals.h)
Signed-off-by: Michael Tokarev <[email protected]>
Commit: 043dea17379564cf6f956bbae6d76a565ef87912
https://github.com/qemu/qemu/commit/043dea17379564cf6f956bbae6d76a565ef87912
Author: Alex Bennée <[email protected]>
Date: 2025-03-09 (Sun, 09 Mar 2025)
Changed paths:
M include/hw/arm/bsa.h
M target/arm/cpu.c
M target/arm/cpu.h
M target/arm/gtimer.h
M target/arm/helper.c
Log Message:
-----------
target/arm: Implement SEL2 physical and virtual timers
When FEAT_SEL2 was implemented the SEL2 timers were missed. This
shows up when building the latest Hafnium with SPMC_AT_EL=2. The
actual implementation utilises the same logic as the rest of the
timers so all we need to do is:
- define the timers and their access functions
- conditionally add the correct system registers
- create a new accessfn as the rules are subtly different to the
existing secure timer
Fixes: e9152ee91c (target/arm: add ARMv8.4-SEL2 system registers)
Signed-off-by: Alex Bennée <[email protected]>
Signed-off-by: Peter Maydell <[email protected]>
Reviewed-by: Peter Maydell <[email protected]>
Message-id: [email protected]
Cc: [email protected]
Cc: Andrei Homescu <[email protected]>
Cc: Arve Hjønnevåg <[email protected]>
Cc: Rémi Denis-Courmont <[email protected]>
[PMM: CP_ACCESS_TRAP_UNCATEGORIZED -> CP_ACCESS_UNDEFINED;
offset logic now in gt_{indirect,direct}_access_timer_offset() ]
Reviewed-by: Peter Maydell <[email protected]>
Signed-off-by: Peter Maydell <[email protected]>
(cherry picked from commit f9f99d7ca522339c1de2292f132bb8ddc3471c39)
Signed-off-by: Michael Tokarev <[email protected]>
Commit: 3c4007cbe1fa8f4fbcece59f02f6a581141fc7e4
https://github.com/qemu/qemu/commit/3c4007cbe1fa8f4fbcece59f02f6a581141fc7e4
Author: Alex Bennée <[email protected]>
Date: 2025-03-09 (Sun, 09 Mar 2025)
Changed paths:
M hw/arm/virt.c
Log Message:
-----------
hw/arm: enable secure EL2 timers for virt machine
Signed-off-by: Alex Bennée <[email protected]>
Signed-off-by: Peter Maydell <[email protected]>
Reviewed-by: Peter Maydell <[email protected]>
Message-id: [email protected]
Cc: [email protected]
Reviewed-by: Peter Maydell <[email protected]>
Signed-off-by: Peter Maydell <[email protected]>
(cherry picked from commit 5dcaea8bcd82972add29eef350547f922fb4caa2)
Signed-off-by: Michael Tokarev <[email protected]>
Commit: 8265609eda7810f7fb5965ef8b72a9a6ffdc7b25
https://github.com/qemu/qemu/commit/8265609eda7810f7fb5965ef8b72a9a6ffdc7b25
Author: Alex Bennée <[email protected]>
Date: 2025-03-09 (Sun, 09 Mar 2025)
Changed paths:
M hw/arm/sbsa-ref.c
Log Message:
-----------
hw/arm: enable secure EL2 timers for sbsa machine
Signed-off-by: Alex Bennée <[email protected]>
Reviewed-by: Peter Maydell <[email protected]>
Signed-off-by: Peter Maydell <[email protected]>
Message-id: [email protected]
Cc: [email protected]
Signed-off-by: Peter Maydell <[email protected]>
(cherry picked from commit 9a9d9e82093efa22e3e2bdaac0f24c823f8786f7)
Signed-off-by: Michael Tokarev <[email protected]>
Commit: c82520f0bbc0a21a5bca8d53150a43fab1312737
https://github.com/qemu/qemu/commit/c82520f0bbc0a21a5bca8d53150a43fab1312737
Author: Peter Maydell <[email protected]>
Date: 2025-03-09 (Sun, 09 Mar 2025)
Changed paths:
M target/arm/tcg/translate.c
Log Message:
-----------
target/arm: Correct LDRD atomicity and fault behaviour
Our LDRD implementation is wrong in two respects:
* if the address is 4-aligned and the load crosses a page boundary
and the second load faults and the first load was to the
base register (as in cases like "ldrd r2, r3, [r2]", then we
must not update the base register before taking the fault
* if the address is 8-aligned the access must be a 64-bit
single-copy atomic access, not two 32-bit accesses
Rewrite the handling of the loads in LDRD to use a single
tcg_gen_qemu_ld_i64() and split the result into the destination
registers. This allows us to get the atomicity requirements
right, and also implicitly means that we won't update the
base register too early for the page-crossing case.
Note that because we no longer increment 'addr' by 4 in the course of
performing the LDRD we must change the adjustment value we pass to
op_addr_ri_post() and op_addr_rr_post(): it no longer needs to
subtract 4 to get the correct value to use if doing base register
writeback.
STRD has the same problem with not getting the atomicity right;
we will deal with that in the following commit.
Cc: [email protected]
Reported-by: Stu Grossman <[email protected]>
Signed-off-by: Peter Maydell <[email protected]>
Reviewed-by: Richard Henderson <[email protected]>
Message-id: [email protected]
(cherry picked from commit cde3247651dc998da5dc1005148302a90d72f21f)
Signed-off-by: Michael Tokarev <[email protected]>
Commit: 89a8f9d90198332309995d3773f23c133dabe4a1
https://github.com/qemu/qemu/commit/89a8f9d90198332309995d3773f23c133dabe4a1
Author: Peter Maydell <[email protected]>
Date: 2025-03-09 (Sun, 09 Mar 2025)
Changed paths:
M target/arm/tcg/translate.c
Log Message:
-----------
target/arm: Correct STRD atomicity
Our STRD implementation doesn't correctly implement the requirement:
* if the address is 8-aligned the access must be a 64-bit
single-copy atomic access, not two 32-bit accesses
Rewrite the handling of STRD to use a single tcg_gen_qemu_st_i64()
of a value produced by concatenating the two 32 bit source registers.
This allows us to get the atomicity right.
As with the LDRD change, now that we don't update 'addr' in the
course of performing the store we need to adjust the offset
we pass to op_addr_ri_post() and op_addr_rr_post().
Cc: [email protected]
Signed-off-by: Peter Maydell <[email protected]>
Reviewed-by: Richard Henderson <[email protected]>
Message-id: [email protected]
(cherry picked from commit ee786ca115045a2b7e86ac3073b0761cb99e0d49)
Signed-off-by: Michael Tokarev <[email protected]>
Commit: 473fd335f0af63348b9c4ca20d2e43b78889306b
https://github.com/qemu/qemu/commit/473fd335f0af63348b9c4ca20d2e43b78889306b
Author: Peter Maydell <[email protected]>
Date: 2025-03-09 (Sun, 09 Mar 2025)
Changed paths:
M util/qemu-timer.c
Log Message:
-----------
util/qemu-timer.c: Don't warp timer from timerlist_rearm()
Currently we call icount_start_warp_timer() from timerlist_rearm().
This produces incorrect behaviour, because timerlist_rearm() is
called, for instance, when a timer callback modifies its timer. We
cannot decide here to warp the timer forwards to the next timer
deadline merely because all_cpu_threads_idle() is true, because the
timer callback we were called from (or some other callback later in
the list of callbacks being invoked) may be about to raise a CPU
interrupt and move a CPU from idle to ready.
The only valid place to choose to warp the timer forward is from the
main loop, when we know we have no outstanding IO or timer callbacks
that might be about to wake up a CPU.
For Arm guests, this bug was mostly latent until the refactoring
commit f6fc36deef6abc ("target/arm/helper: Implement
CNTHCTL_EL2.CNT[VP]MASK"), which exposed it because it refactored a
timer callback so that it happened to call timer_mod() first and
raise the interrupt second, when it had previously raised the
interrupt first and called timer_mod() afterwards.
This call seems to have originally derived from the
pre-record-and-replay icount code, which (as of e.g. commit
db1a49726c3c in 2010) in this location did a call to
qemu_notify_event(), necessary to get the icount code in the vCPU
round-robin thread to stop and recalculate the icount deadline when a
timer was reprogrammed from the IO thread. In current QEMU,
everything is done on the vCPU thread when we are in icount mode, so
there's no need to try to notify another thread here.
I suspect that the other reason why this call was doing icount timer
warping is that it pre-dates commit efab87cf79077a from 2015, which
added a call to icount_start_warp_timer() to main_loop_wait(). Once
the call in timerlist_rearm() has been removed, if the timer
callbacks don't cause any CPU to be woken up then we will end up
calling icount_start_warp_timer() from main_loop_wait() when the rr
main loop code calls rr_wait_io_event().
Remove the incorrect call from timerlist_rearm().
Cc: [email protected]
Resolves: https://gitlab.com/qemu-project/qemu/-/issues/2703
Signed-off-by: Peter Maydell <[email protected]>
Reviewed-by: Richard Henderson <[email protected]>
Reviewed-by: Alex Bennée <[email protected]>
Tested-by: Alex Bennée <[email protected]>
Message-id: [email protected]
(cherry picked from commit 02ae315467cee589d02dfb89e13a2a6a8de09fc5)
Signed-off-by: Michael Tokarev <[email protected]>
Commit: ad38b26f3be550e592fcca5762296b7cf7028550
https://github.com/qemu/qemu/commit/ad38b26f3be550e592fcca5762296b7cf7028550
Author: Eugenio Pérez <[email protected]>
Date: 2025-03-11 (Tue, 11 Mar 2025)
Changed paths:
M net/net.c
Log Message:
-----------
net: parameterize the removing client from nc list
This change is used in later commits so we can avoid the removal of the
netclient if it is delayed.
No functional change intended.
Reviewed-by: Si-Wei Liu <[email protected]>
Acked-by: Jason Wang <[email protected]>
Signed-off-by: Eugenio Pérez <[email protected]>
Signed-off-by: Jason Wang <[email protected]>
(cherry picked from commit db0d4017f9b9e87f962b35dd19a4912bbfcd3cbc)
(Mjt: pick this one up for the following change,
"net: move backend cleanup to NIC cleanup")
Signed-off-by: Michael Tokarev <[email protected]>
Commit: e1b3d02898d2e3488c10e7ac8cd8d8b531091bf6
https://github.com/qemu/qemu/commit/e1b3d02898d2e3488c10e7ac8cd8d8b531091bf6
Author: Eugenio Pérez <[email protected]>
Date: 2025-03-11 (Tue, 11 Mar 2025)
Changed paths:
M net/net.c
M net/vhost-vdpa.c
Log Message:
-----------
net: move backend cleanup to NIC cleanup
Commit a0d7215e33 ("vhost-vdpa: do not cleanup the vdpa/vhost-net
structures if peer nic is present") effectively delayed the backend
cleanup, allowing the frontend or the guest to access it resources as
long as the frontend is still visible to the guest.
However it does not clean up the resources until the qemu process is
over. This causes an effective leak if the device is deleted with
device_del, as there is no way to close the vdpa device. This makes
impossible to re-add that device to this or other QEMU instances until
the first instance of QEMU is finished.
Move the cleanup from qemu_cleanup to the NIC deletion and to
net_cleanup.
Fixes: a0d7215e33 ("vhost-vdpa: do not cleanup the vdpa/vhost-net structures if
peer nic is present")
Reported-by: Lei Yang <[email protected]>
Signed-off-by: Eugenio Pérez <[email protected]>
Signed-off-by: Jonah Palmer <[email protected]>
Signed-off-by: Jason Wang <[email protected]>
(cherry picked from commit e7891c575fb294618b172119a91c892b8f4384a2)
Signed-off-by: Michael Tokarev <[email protected]>
Commit: 750013a3f4e3db1eed448c28fd44d4ca2feb0545
https://github.com/qemu/qemu/commit/750013a3f4e3db1eed448c28fd44d4ca2feb0545
Author: Stefano Stabellini <[email protected]>
Date: 2025-03-11 (Tue, 11 Mar 2025)
Changed paths:
M hw/xen/xen-mapcache.c
Log Message:
-----------
xen: No need to flush the mapcache for grants
On IOREQ_TYPE_INVALIDATE we need to invalidate the mapcache for regular
mappings. Since recently we started reusing the mapcache also to keep
track of grants mappings. However, there is no need to remove grant
mappings on IOREQ_TYPE_INVALIDATE requests, we shouldn't do that. So
remove the function call.
Fixes: 9ecdd4bf08 (xen: mapcache: Add support for grant mappings)
Cc: [email protected]
Reported-by: Olaf Hering <[email protected]>
Reviewed-by: Edgar E. Iglesias <[email protected]>
Signed-off-by: Stefano Stabellini <[email protected]>
Signed-off-by: Edgar E. Iglesias <[email protected]>
Reviewed-by: Anthony PERARD <[email protected]>
Message-Id: <[email protected]>
Signed-off-by: Anthony PERARD <[email protected]>
(cherry picked from commit 68adcc784bad13421ac7211c316a751fb99fcb94)
Signed-off-by: Michael Tokarev <[email protected]>
Commit: 4fcb319fc887968f8237f0e02419b9c4e12067da
https://github.com/qemu/qemu/commit/4fcb319fc887968f8237f0e02419b9c4e12067da
Author: Nicholas Piggin <[email protected]>
Date: 2025-03-13 (Thu, 13 Mar 2025)
Changed paths:
M hw/ppc/pnv_occ.c
Log Message:
-----------
ppc/pnv/occ: Fix common area sensor offsets
The commit to fix the OCC common area sensor mappings didn't update the
register offsets to match.
Before this change, skiboot reports:
[ 0.347100086,3] OCC: Chip 0 sensor data invalid
Afterward, there is no error and the sensor_groups directory appears
under /sys/firmware/opal/.
The SLW_IMAGE_BASE address looks like a workaround to intercept firmware
memory accesses, but that does not seem to be required now (and would
have been broken by the OCC common area region mapping change anyway).
So it can be removed.
Fixes: 3a1b70b66b5cb4 ("ppc/pnv: Fix OCC common area region mapping")
Signed-off-by: Nicholas Piggin <[email protected]>
(cherry picked from commit 29c041ca7f8d6910c894788482efff892789dcd2)
Signed-off-by: Michael Tokarev <[email protected]>
Commit: ca67dc908c283a970a5cd096a9949ab845ff6d48
https://github.com/qemu/qemu/commit/ca67dc908c283a970a5cd096a9949ab845ff6d48
Author: Peter Maydell <[email protected]>
Date: 2025-03-13 (Thu, 13 Mar 2025)
Changed paths:
M hw/net/smc91c111.c
Log Message:
-----------
hw/net/smc91c111: Sanitize packet numbers
The smc91c111 uses packet numbers as an index into its internal
s->data[][] array. Valid packet numbers are between 0 and 3, but
the code does not generally check this, and there are various
places where the guest can hand us an arbitrary packet number
and cause an out-of-bounds access to the data array.
Add validation of packet numbers. The datasheet is not very
helpful about how guest errors like this should be handled:
it says nothing on the subject, and none of the documented
error conditions are relevant. We choose to log the situation
with LOG_GUEST_ERROR and silently ignore the attempted operation.
In the places where we are about to access the data[][] array
using a packet number and we know the number is valid because
we got it from somewhere that has already validated, we add
an assert() to document that belief.
Cc: [email protected]
Signed-off-by: Peter Maydell <[email protected]>
Reviewed-by: Philippe Mathieu-Daudé <[email protected]>
Message-ID: <[email protected]>
Signed-off-by: Philippe Mathieu-Daudé <[email protected]>
(cherry picked from commit 2fa3a5b9469615d06091cf473d172794148e1248)
Signed-off-by: Michael Tokarev <[email protected]>
Commit: e2e6bb48037560c8492af59b4717f229165d8d74
https://github.com/qemu/qemu/commit/e2e6bb48037560c8492af59b4717f229165d8d74
Author: Peter Maydell <[email protected]>
Date: 2025-03-13 (Thu, 13 Mar 2025)
Changed paths:
M hw/net/smc91c111.c
Log Message:
-----------
hw/net/smc91c111: Sanitize packet length on tx
When the smc91c111 transmits a packet, it must read a control byte
which is at the end of the data area and CRC. However, we don't
sanitize the length field in the packet buffer, so if the guest sets
the length field to something large we will try to read past the end
of the packet data buffer when we access the control byte.
As usual, the datasheet says nothing about the behaviour of the
hardware if the guest misprograms it in this way. It says only that
the maximum valid length is 2048 bytes. We choose to log the guest
error and silently drop the packet.
This requires us to factor out the "mark the tx packet as complete"
logic, so we can call it for this "drop packet" case as well as at
the end of the loop when we send a valid packet.
Cc: [email protected]
Resolves: https://gitlab.com/qemu-project/qemu/-/issues/2742
Signed-off-by: Peter Maydell <[email protected]>
Reviewed-by: Philippe Mathieu-Daudé <[email protected]>
Message-ID: <[email protected]>
[PMD: Update smc91c111_do_tx() as len > MAX_PACKET_SIZE]
Signed-off-by: Philippe Mathieu-Daudé <[email protected]>
(cherry picked from commit aad6f264add3f2be72acb660816588fe09110069)
Signed-off-by: Michael Tokarev <[email protected]>
Commit: 4e17b941569c58efb6b0e60833c1573021da8816
https://github.com/qemu/qemu/commit/4e17b941569c58efb6b0e60833c1573021da8816
Author: Peter Maydell <[email protected]>
Date: 2025-03-13 (Thu, 13 Mar 2025)
Changed paths:
M hw/net/smc91c111.c
Log Message:
-----------
hw/net/smc91c111: Don't allow data register access to overrun buffer
For accesses to the 91c111 data register, the address within the
packet's data frame is determined by a combination of the pointer
register and the offset used to access the data register, so that you
can access data at effectively wider than byte width. The pointer
register's pointer field is 11 bits wide, which is exactly the size
to index a 2048-byte data frame.
We weren't quite getting the logic right for ensuring that we end up
with a pointer value to use in the s->data[][] array that isn't out
of bounds:
* we correctly mask when getting the initial pointer value
* for the "autoincrement the pointer register" case, we
correctly mask after adding 1 so that the pointer register
wraps back around at the 2048 byte mark
* but for the non-autoincrement case where we have to add the
low 2 bits of the data register offset, we don't account
for the possibility that the pointer register is 0x7ff
and the addition should wrap
Fix this bug by factoring out the "get the p value to use as an array
index" into a function, making it use FIELD macro names rather than
hard-coded constants, and having a utility function that does "add a
value and wrap it" that we can use both for the "autoincrement" and
"add the offset bits" codepaths.
Cc: [email protected]
Resolves: https://gitlab.com/qemu-project/qemu/-/issues/2758
Signed-off-by: Peter Maydell <[email protected]>
Reviewed-by: Philippe Mathieu-Daudé <[email protected]>
Message-ID: <[email protected]>
Signed-off-by: Philippe Mathieu-Daudé <[email protected]>
(cherry picked from commit 700d3d6dd41de3bd3f1153e3cfe00b93f99b1441)
Signed-off-by: Michael Tokarev <[email protected]>
Commit: bf4d531cf8bbef1137c6806330c5eaa882490046
https://github.com/qemu/qemu/commit/bf4d531cf8bbef1137c6806330c5eaa882490046
Author: Philippe Mathieu-Daudé <[email protected]>
Date: 2025-03-13 (Thu, 13 Mar 2025)
Changed paths:
M include/hw/xen/arch_hvm.h
Log Message:
-----------
hw/xen/hvm: Fix Aarch64 typo
There is no TARGET_ARM_64 definition. Luckily enough,
when TARGET_AARCH64 is defined, TARGET_ARM also is.
Fixes: 733766cd373 ("hw/arm: introduce xenpvh machine")
Signed-off-by: Philippe Mathieu-Daudé <[email protected]>
Reviewed-by: Pierrick Bouvier <[email protected]>
Reviewed-by: Richard Henderson <[email protected]>
Message-Id: <[email protected]>
(cherry picked from commit 3a11b653a63fee0e43f4ab84b93f068b961d8fe7)
Signed-off-by: Michael Tokarev <[email protected]>
Commit: 0d9db63ca8a28bec9b3da45b8574e75725787243
https://github.com/qemu/qemu/commit/0d9db63ca8a28bec9b3da45b8574e75725787243
Author: Kevin Wolf <[email protected]>
Date: 2025-03-14 (Fri, 14 Mar 2025)
Changed paths:
M block/snapshot.c
Log Message:
-----------
block: Zero block driver state before reopening
Block drivers assume in their .bdrv_open() implementation that their
state in bs->opaque has been zeroed; it is initially allocated with
g_malloc0() in bdrv_open_driver().
bdrv_snapshot_goto() needs to make sure that it is zeroed again before
calling drv->bdrv_open() to avoid that block drivers use stale values.
One symptom of this bug is VMDK running into a double free when the user
tries to apply an internal snapshot like 'qemu-img snapshot -a test
test.vmdk'. This should be a graceful error because VMDK doesn't support
internal snapshots.
==25507== Invalid free() / delete / delete[] / realloc()
==25507== at 0x484B347: realloc (vg_replace_malloc.c:1801)
==25507== by 0x54B592A: g_realloc (gmem.c:171)
==25507== by 0x1B221D: vmdk_add_extent (../block/vmdk.c:570)
==25507== by 0x1B1084: vmdk_open_sparse (../block/vmdk.c:1059)
==25507== by 0x1AF3D8: vmdk_open (../block/vmdk.c:1371)
==25507== by 0x1A2AE0: bdrv_snapshot_goto (../block/snapshot.c:299)
==25507== by 0x205C77: img_snapshot (../qemu-img.c:3500)
==25507== by 0x58FA087: (below main) (libc_start_call_main.h:58)
==25507== Address 0x832f3e0 is 0 bytes inside a block of size 272 free'd
==25507== at 0x4846B83: free (vg_replace_malloc.c:989)
==25507== by 0x54AEAC4: g_free (gmem.c:208)
==25507== by 0x1AF629: vmdk_close (../block/vmdk.c:2889)
==25507== by 0x1A2A9C: bdrv_snapshot_goto (../block/snapshot.c:290)
==25507== by 0x205C77: img_snapshot (../qemu-img.c:3500)
==25507== by 0x58FA087: (below main) (libc_start_call_main.h:58)
This error was discovered by fuzzing qemu-img.
Cc: [email protected]
Closes: https://gitlab.com/qemu-project/qemu/-/issues/2853
Closes: https://gitlab.com/qemu-project/qemu/-/issues/2851
Reported-by: Denis Rastyogin <[email protected]>
Signed-off-by: Kevin Wolf <[email protected]>
Message-ID: <[email protected]>
Signed-off-by: Kevin Wolf <[email protected]>
(cherry picked from commit b75c5f9879166b86ed7c48b772fdcd0693e8a9a3)
Signed-off-by: Michael Tokarev <[email protected]>
Commit: 182a5b510fc777ddcbb5d8d4266ccd649b818f8a
https://github.com/qemu/qemu/commit/182a5b510fc777ddcbb5d8d4266ccd649b818f8a
Author: Greg Kurz <[email protected]>
Date: 2025-03-14 (Fri, 14 Mar 2025)
Changed paths:
M docs/devel/build-system.rst
M docs/devel/kconfig.rst
Log Message:
-----------
docs: Rename default-configs to configs
This was missed at the time.
Fixes: 812b31d3f91 ("configs: rename default-configs to configs and reorganise")
Signed-off-by: Greg Kurz <[email protected]>
Reviewed-by: Philippe Mathieu-Daudé <[email protected]>
Message-ID: <[email protected]>
Signed-off-by: Thomas Huth <[email protected]>
(cherry picked from commit 48170c2d865a5937092b1384421b01cd38113042)
Signed-off-by: Michael Tokarev <[email protected]>
Compare: https://github.com/qemu/qemu/compare/ea35a5082a5f...182a5b510fc7
To unsubscribe from these emails, change your notification settings at
https://github.com/qemu/qemu/settings/notifications
