Branch: refs/heads/master
Home: https://github.com/qemu/qemu
Commit: 47de28a0b7fb96531271aaeaa3e7f2cad2b91221
https://github.com/qemu/qemu/commit/47de28a0b7fb96531271aaeaa3e7f2cad2b91221
Author: Xianglai Li <[email protected]>
Date: 2026-01-15 (Thu, 15 Jan 2026)
Changed paths:
M hw/loongarch/virt-fdt-build.c
Log Message:
-----------
hw/loongarch/virt: Modify the interrupt trigger type in fdt table
In the loongarch virt fdt file, the interrupt trigger type directly
uses magic numbers. Now, refer to the definitions in the linux kernel and
use macro definitions.
Signed-off-by: Xianglai Li <[email protected]>
Signed-off-by: Bibo Mao <[email protected]>
Reviewed-by: Bibo Mao <[email protected]>
Commit: ff54394eed148c642f83b45753c7898acdbd5ddb
https://github.com/qemu/qemu/commit/ff54394eed148c642f83b45753c7898acdbd5ddb
Author: Xianglai Li <[email protected]>
Date: 2026-01-15 (Thu, 15 Jan 2026)
Changed paths:
M hw/loongarch/virt-fdt-build.c
Log Message:
-----------
hw/loongarch/virt: Fix irq allocation failure with pci device from fdt
When we use the -kernel parameter to start an elf format kernel relying on
fdt, we get the following error:
pcieport 0000:00:01.0: of_irq_parse_pci: failed with rc=-22
pcieport 0000:00:01.0: enabling device (0000 -> 0003)
pcieport 0000:00:01.0: PME: Signaling with IRQ 19
pcieport 0000:00:01.0: AER: enabled with IRQ 19
pcieport 0000:00:01.1: of_irq_parse_pci: failed with rc=-22
pcieport 0000:00:01.1: enabling device (0000 -> 0003)
pcieport 0000:00:01.1: PME: Signaling with IRQ 20
pcieport 0000:00:01.1: AER: enabled with IRQ 20
pcieport 0000:00:01.2: of_irq_parse_pci: failed with rc=-22
pcieport 0000:00:01.2: enabling device (0000 -> 0003)
pcieport 0000:00:01.2: PME: Signaling with IRQ 21
pcieport 0000:00:01.2: AER: enabled with IRQ 21
pcieport 0000:00:01.3: of_irq_parse_pci: failed with rc=-22
pcieport 0000:00:01.3: enabling device (0000 -> 0003)
pcieport 0000:00:01.3: PME: Signaling with IRQ 22
pcieport 0000:00:01.3: AER: enabled with IRQ 22
pcieport 0000:00:01.4: of_irq_parse_pci: failed with rc=-22
This is because the description of interrupt-cell is missing in the pcie
irq map. And there is a lack of a description of the interrupt trigger
type. Now it is corrected and the correct interrupt-cell is added in the
pcie irq map.
Refer to the implementation in arm and add some comments.
Signed-off-by: Xianglai Li <[email protected]>
Signed-off-by: Bibo Mao <[email protected]>
Reviewed-by: Bibo Mao <[email protected]>
Commit: 70cf9b7bf7aff47f8d85ccce35b688dd91335cf0
https://github.com/qemu/qemu/commit/70cf9b7bf7aff47f8d85ccce35b688dd91335cf0
Author: Song Gao <[email protected]>
Date: 2026-01-15 (Thu, 15 Jan 2026)
Changed paths:
M target/loongarch/tcg/tcg_cpu.c
Log Message:
-----------
target/loongach: Fix some exceptions failure in updating CSR_BADV
According to Volume 1 Manual 7.4.8 ,exception,SYS,BRK,INE,IPE,PPD
FPE,SXD,ASXD are need't update CSR_BADV, this patch correct it.
Signed-off-by: Song Gao <[email protected]>
Signed-off-by: Bibo Mao <[email protected]>
Reviewed-by: Bibo Mao <[email protected]>
Commit: e4f0ef58d53eb20056f9f3ca9f21dbbbf25f2530
https://github.com/qemu/qemu/commit/e4f0ef58d53eb20056f9f3ca9f21dbbbf25f2530
Author: Song Gao <[email protected]>
Date: 2026-01-15 (Thu, 15 Jan 2026)
Changed paths:
M target/loongarch/tcg/tcg_cpu.c
Log Message:
-----------
target/loongarch: Fix exception BCE missing to update CSR_BADV
Exception BCE need update CSR_BADV, and the value is env->pc.
Signed-off-by: Song Gao <[email protected]>
Signed-off-by: Bibo Mao <[email protected]>
Reviewed-by: Bibo Mao <[email protected]>
Commit: a7be2e0a3f7d0f35bcc3b17e2b558084efc5d9fe
https://github.com/qemu/qemu/commit/a7be2e0a3f7d0f35bcc3b17e2b558084efc5d9fe
Author: Song Gao <[email protected]>
Date: 2026-01-15 (Thu, 15 Jan 2026)
Changed paths:
M target/loongarch/tcg/tcg_cpu.c
Log Message:
-----------
target/loongarch: Fix exception ADEF/ADEM missing to update CSR_BADV
Exception ADEM/ADEF need update CSR_BADV, the value from the virtual
address.
Signed-off-by: Song Gao <[email protected]>
Signed-off-by: Bibo Mao <[email protected]>
Reviewed-by: Bibo Mao <[email protected]>
Commit: 49ee001a5b8378e9a9b3db8cbf61e7eda970ecd2
https://github.com/qemu/qemu/commit/49ee001a5b8378e9a9b3db8cbf61e7eda970ecd2
Author: Yao Zi <[email protected]>
Date: 2026-01-15 (Thu, 15 Jan 2026)
Changed paths:
M hw/loongarch/virt.c
Log Message:
-----------
hw/loongarch/virt: Don't abort on access to unimplemented IOCSR
Since commit f2e61edb2946 ("hw/loongarch/virt: Use MemTxAttrs interface
for misc ops") which adds a call to g_assert_not_reached() in the path
of handling unimplemented IOCSRs, QEMU would abort when the guest
accesses unimplemented IOCSRs.
This is too serious since there's nothing fatal happening in QEMU
itself, and the guest could probably continue running if we give zero as
result for these reads, which also matches the behavior observed on
3A5000M real machine.
Replace the assertion with qemu_log_mask(LOG_UNIMP, ...), it's still
possible to examine unimplemented IOCSR access through "-d unimp"
command line arguments.
Fixes: f2e61edb2946 ("hw/loongarch/virt: Use MemTxAttrs interface for misc ops")
Signed-off-by: Yao Zi <[email protected]>
Signed-off-by: Bibo Mao <[email protected]>
Reviewed-by: Philippe Mathieu-Daudé <[email protected]>
Reviewed-by: Bibo Mao <[email protected]>
Commit: 0900f43715faf01e6e2ed3afe6ac7ffad8995e57
https://github.com/qemu/qemu/commit/0900f43715faf01e6e2ed3afe6ac7ffad8995e57
Author: Osama Abdelkader <[email protected]>
Date: 2026-01-15 (Thu, 15 Jan 2026)
Changed paths:
M hw/arm/raspi.c
Log Message:
-----------
hw/arm/raspi: remove duplicate include
hw/arm/boot.h is included twice
Signed-off-by: Osama Abdelkader <[email protected]>
Reviewed-by: Peter Maydell <[email protected]>
Signed-off-by: Peter Maydell <[email protected]>
Commit: 153a15e9f5ec25d90a9921b631104c91d9880dd6
https://github.com/qemu/qemu/commit/153a15e9f5ec25d90a9921b631104c91d9880dd6
Author: Jim MacArthur <[email protected]>
Date: 2026-01-15 (Thu, 15 Jan 2026)
Changed paths:
M target/arm/cpu-sysregs.h.inc
M target/arm/helper.c
Log Message:
-----------
target/arm: Enable ID_AA64MMFR4_EL1 register
Reviewed-by: Richard Henderson <[email protected]>
Reviewed-by: Alex Bennée <[email protected]>
Reviewed-by: Gustavo Romero <[email protected]>
Signed-off-by: Jim MacArthur <[email protected]>
[PMM: add entry to v8_user_idregs[] list also]
Signed-off-by: Peter Maydell <[email protected]>
Commit: 42f13215fe4c322ad6bb3fc28fcb2d3ce8070869
https://github.com/qemu/qemu/commit/42f13215fe4c322ad6bb3fc28fcb2d3ce8070869
Author: Jim MacArthur <[email protected]>
Date: 2026-01-15 (Thu, 15 Jan 2026)
Changed paths:
M target/arm/cpu-features.h
M target/arm/helper.c
M target/arm/internals.h
Log Message:
-----------
target/arm: Allow writes to FNG1, FNG0, A2
This just allows read/write of three feature bits. ASID is still
ignored. Any writes to TTBR0_EL0 and TTBR1_EL0, including changing
the ASID, will still cause a complete flush of the TLB.
Signed-off-by: Jim MacArthur <[email protected]>
Reviewed-by: Richard Henderson <[email protected]>
Signed-off-by: Peter Maydell <[email protected]>
Commit: 672a1dd1ed051b252fa93094a8d064a24197bcfe
https://github.com/qemu/qemu/commit/672a1dd1ed051b252fa93094a8d064a24197bcfe
Author: Jim MacArthur <[email protected]>
Date: 2026-01-15 (Thu, 15 Jan 2026)
Changed paths:
M docs/system/arm/emulation.rst
M target/arm/tcg/cpu64.c
Log Message:
-----------
target/arm/tcg/cpu64.c: Enable ASID2 for cpu_max
docs/system/arm/emulation.rst: Add ASID2
Reviewed-by: Gustavo Romero <[email protected]>
Signed-off-by: Jim MacArthur <[email protected]>
Reviewed-by: Richard Henderson <[email protected]>
Signed-off-by: Peter Maydell <[email protected]>
Commit: bb5ce7dc56c87cfa800a673b59bb31fdac2a3ac8
https://github.com/qemu/qemu/commit/bb5ce7dc56c87cfa800a673b59bb31fdac2a3ac8
Author: Jim MacArthur <[email protected]>
Date: 2026-01-15 (Thu, 15 Jan 2026)
Changed paths:
A tests/tcg/aarch64/system/asid2.c
Log Message:
-----------
tests: Add test for ASID2 and write/read of feature bits
Test for presence of ASID2; if it is, check FNG1, FNG0, and A2 are
writable, and read value shows the update. If not present, check these
read as RES0.
Reviewed-by: Alex Bennée <[email protected]>
Signed-off-by: Jim MacArthur <[email protected]>
Signed-off-by: Peter Maydell <[email protected]>
Commit: 9111971f3350e00df2fe10112e5796a434915579
https://github.com/qemu/qemu/commit/9111971f3350e00df2fe10112e5796a434915579
Author: julia <[email protected]>
Date: 2026-01-15 (Thu, 15 Jan 2026)
Changed paths:
M hw/char/cmsdk-apb-uart.c
Log Message:
-----------
hw/char/cmsdk-apb-uart.c: log guest_errors for r/w to disabled uart
I don't want to admit how many hours I spent trying to figure out why
nothing was being printed (as the enable-ing code hadn't yet run,
even thought it existed).
Signed-off-by: julia <[email protected]>
Reviewed-by: Philippe Mathieu-Daudé <[email protected]>
Message-id: 20251217-cmsdk-uart-disabled-warning2-v1-1-847de4884...@trainwit.ch
Signed-off-by: Peter Maydell <[email protected]>
Commit: c5712ad83fa4bf2f2a4e8fc9431ad9548bac2b06
https://github.com/qemu/qemu/commit/c5712ad83fa4bf2f2a4e8fc9431ad9548bac2b06
Author: Philippe Mathieu-Daudé <[email protected]>
Date: 2026-01-15 (Thu, 15 Jan 2026)
Changed paths:
M hw/arm/max78000fthr.c
Log Message:
-----------
hw/arm: Re-enable the MAX78000FTHR machine in qemu-system-arm/aarch64
Unfortunately while rebasing the series registering the
ARM/Aarch64 machine interfaces and getting it merged as
commit 38c5ab40031 ("hw/arm: Filter machine types for
qemu-system-arm/aarch64 binaries") we missed the recent
addition of the MAX78000FTHR machine in commit 51eb283dd0e.
Correct that.
The effect is that the machine was accidentally disabled.
Cc: [email protected]
Reported-by: Thomas Huth <[email protected]>
Tested-by: Thomas Huth <[email protected]>
Tested-by: Markus Armbruster <[email protected]>
Signed-off-by: Philippe Mathieu-Daudé <[email protected]>
Message-id: [email protected]
Resolves: https://gitlab.com/qemu-project/qemu/-/issues/3248
Fixes: 38c5ab40031 ("hw/arm: Filter machine types for single binary")
Signed-off-by: Peter Maydell <[email protected]>
Commit: a14503827d32f51e71cfd93e0a8a0badc29b2c56
https://github.com/qemu/qemu/commit/a14503827d32f51e71cfd93e0a8a0badc29b2c56
Author: Tao Tang <[email protected]>
Date: 2026-01-15 (Thu, 15 Jan 2026)
Changed paths:
A include/hw/arm/arm-security.h
M target/arm/cpu.h
Log Message:
-----------
target/arm: Move ARMSecuritySpace to a common header
The ARMSecuritySpace enum and its related helpers were defined in the
target-specific header target/arm/cpu.h. This prevented common,
target-agnostic code like the SMMU model from using these definitions
without triggering "cpu.h included from common code" errors.
To resolve this, this commit introduces a new, lightweight header,
include/hw/arm/arm-security.h, which is safe for inclusion by common
code.
The following change was made:
- The ARMSecuritySpace enum and the arm_space_is_secure() and
arm_secure_to_space() helpers have been moved from target/arm/cpu.h
to the new hw/arm/arm-security.h header.
This refactoring decouples the security state definitions from the core
CPU implementation, allowing common hardware models to correctly handle
security states without pulling in heavyweight, target-specific headers.
Signed-off-by: Tao Tang <[email protected]>
Reviewed-by: Eric Auger <[email protected]>
Reviewed-by: Richard Henderson <[email protected]>
Signed-off-by: Pierrick Bouvier <[email protected]>
Reviewed-by: Philippe Mathieu-Daudé <[email protected]>
Message-id: [email protected]
Link: https://lists.nongnu.org/archive/html/qemu-arm/2025-09/msg01288.html
Signed-off-by: Pierrick Bouvier <[email protected]>
Signed-off-by: Peter Maydell <[email protected]>
Commit: df2f43555c636c73e97855f506c5a16f8cf2ab03
https://github.com/qemu/qemu/commit/df2f43555c636c73e97855f506c5a16f8cf2ab03
Author: Pierrick Bouvier <[email protected]>
Date: 2026-01-15 (Thu, 15 Jan 2026)
Changed paths:
M target/arm/cpu.h
M target/arm/ptw.c
Log Message:
-----------
target/arm/ptw: make granule_protection_check usable without a cpu
By removing cpu details and use a config struct, we can use the
same granule_protection_check with other devices, like SMMU.
Signed-off-by: Pierrick Bouvier <[email protected]>
Reviewed-by: Richard Henderson <[email protected]>
Message-id: [email protected]
[PMM: avoid local vars in middle of block]
Signed-off-by: Peter Maydell <[email protected]>
Commit: 4d353e1228d56b9b67178e49e25e207d321f7ec7
https://github.com/qemu/qemu/commit/4d353e1228d56b9b67178e49e25e207d321f7ec7
Author: Peter Maydell <[email protected]>
Date: 2026-01-15 (Thu, 15 Jan 2026)
Changed paths:
M hw/sd/omap_mmc.c
Log Message:
-----------
hw/sd/omap_mmc: Remove omap_badwidth_* calls
The omap_badwidth_read* and omap_badwidth_write* functions are
used by various OMAP devices when the guest makes an access
to registers with an invalid width; they do two things:
- log a GUEST_ERROR for the access
- call cpu_physical_memory_read() or cpu_physical_memory_write()
with the offset they are passed in
The first of these produces an unhelpful log message because the
function name that is printed is that of the omap-badwidth_*
function, not that of the read or write function of the device that
called it; this means you can't tell what device is involved.
The second is wrong because the offset is an offset into the device
but we use it as an absolute physical address, so we will access
whatever is at low memory. That happens to be the boot ROM, so we
will ignore a write and return random garbage on a read. This bug
has been present since 2011, when we did the conversions to the
MemoryRegion APIs, which involved changing all devices from working
with absolute physical addresses to working with offsets within their
MemoryRegions. We must have missed updating these functions.
Replace the uses of these functions in omap_mmc.c with an
open-coded call to qemu_log_mask() and RAZ/WI behaviour.
Signed-off-by: Peter Maydell <[email protected]>
Reviewed-by: Philippe Mathieu-Daudé <[email protected]>
Commit: f2368e9d67a0c6833164e8a99f4aef41467d665a
https://github.com/qemu/qemu/commit/f2368e9d67a0c6833164e8a99f4aef41467d665a
Author: Peter Maydell <[email protected]>
Date: 2026-01-15 (Thu, 15 Jan 2026)
Changed paths:
M hw/i2c/omap_i2c.c
Log Message:
-----------
hw/i2c/omap_i2c: Remove omap_badwidth_* calls
The omap_badwidth_read* and omap_badwidth_write* functions are
used by various OMAP devices when the guest makes an access
to registers with an invalid width; they do two things:
- log a GUEST_ERROR for the access
- call cpu_physical_memory_read() or cpu_physical_memory_write()
with the offset they are passed in
The first of these produces an unhelpful log message because the
function name that is printed is that of the omap-badwidth_*
function, not that of the read or write function of the device that
called it; this means you can't tell what device is involved.
The second is wrong because the offset is an offset into the device
but we use it as an absolute physical address, so we will access
whatever is at low memory. That happens to be the boot ROM, so we
will ignore a write and return random garbage on a read. This bug
has been present since 2011, when we did the conversions to the
MemoryRegion APIs, which involved changing all devices from working
with absolute physical addresses to working with offsets within their
MemoryRegions. We must have missed updating these functions.
Replace the uses of these functions in omap_i2c.c with an
open-coded call to qemu_log_mask() and RAZ/WI behaviour.
Signed-off-by: Peter Maydell <[email protected]>
Reviewed-by: Philippe Mathieu-Daudé <[email protected]>
Commit: cf8552eb4c2dcdf195b34463b3a7d5c16be1328c
https://github.com/qemu/qemu/commit/cf8552eb4c2dcdf195b34463b3a7d5c16be1328c
Author: Peter Maydell <[email protected]>
Date: 2026-01-15 (Thu, 15 Jan 2026)
Changed paths:
M hw/gpio/omap_gpio.c
Log Message:
-----------
hw/gpio/omap_gpio: Remove omap_badwidth_* calls
The omap_badwidth_read* and omap_badwidth_write* functions are
used by various OMAP devices when the guest makes an access
to registers with an invalid width; they do two things:
- log a GUEST_ERROR for the access
- call cpu_physical_memory_read() or cpu_physical_memory_write()
with the offset they are passed in
The first of these produces an unhelpful log message because the
function name that is printed is that of the omap-badwidth_*
function, not that of the read or write function of the device that
called it; this means you can't tell what device is involved.
The second is wrong because the offset is an offset into the device
but we use it as an absolute physical address, so we will access
whatever is at low memory. That happens to be the boot ROM, so we
will ignore a write and return random garbage on a read. This bug
has been present since 2011, when we did the conversions to the
MemoryRegion APIs, which involved changing all devices from working
with absolute physical addresses to working with offsets within their
MemoryRegions. We must have missed updating these functions.
Replace the uses of these functions in omap_gpio.c with an
open-coded call to qemu_log_mask() and RAZ/WI behaviour.
Signed-off-by: Peter Maydell <[email protected]>
Reviewed-by: Philippe Mathieu-Daudé <[email protected]>
Commit: 0dbc2392d8ef0cefff6f07cf5e653e2eadb97f5a
https://github.com/qemu/qemu/commit/0dbc2392d8ef0cefff6f07cf5e653e2eadb97f5a
Author: Peter Maydell <[email protected]>
Date: 2026-01-15 (Thu, 15 Jan 2026)
Changed paths:
M hw/dma/omap_dma.c
Log Message:
-----------
hw/dma/omap_dma: Remove omap_badwidth_* calls
The omap_badwidth_read* and omap_badwidth_write* functions are
used by various OMAP devices when the guest makes an access
to registers with an invalid width; they do two things:
- log a GUEST_ERROR for the access
- call cpu_physical_memory_read() or cpu_physical_memory_write()
with the offset they are passed in
The first of these produces an unhelpful log message because the
function name that is printed is that of the omap-badwidth_*
function, not that of the read or write function of the device that
called it; this means you can't tell what device is involved.
The second is wrong because the offset is an offset into the device
but we use it as an absolute physical address, so we will access
whatever is at low memory. That happens to be the boot ROM, so we
will ignore a write and return random garbage on a read. This bug
has been present since 2011, when we did the conversions to the
MemoryRegion APIs, which involved changing all devices from working
with absolute physical addresses to working with offsets within their
MemoryRegions. We must have missed updating these functions.
Replace the uses of these functions in omap_dma.c with an
open-coded call to qemu_log_mask() and RAZ/WI behaviour.
Signed-off-by: Peter Maydell <[email protected]>
Reviewed-by: Philippe Mathieu-Daudé <[email protected]>
Commit: 21d3cac1abbc74d7b39245fcc8f811061fb18290
https://github.com/qemu/qemu/commit/21d3cac1abbc74d7b39245fcc8f811061fb18290
Author: Peter Maydell <[email protected]>
Date: 2026-01-15 (Thu, 15 Jan 2026)
Changed paths:
M hw/arm/omap1.c
Log Message:
-----------
hw/arm/omap1: Remove omap_badwidth_read* calls
The omap_badwidth_read* and omap_badwidth_write* functions are
used by various OMAP devices when the guest makes an access
to registers with an invalid width; they do two things:
- log a GUEST_ERROR for the access
- call cpu_physical_memory_read() or cpu_physical_memory_write()
with the offset they are passed in
The first of these produces an unhelpful log message because the
function name that is printed is that of the omap-badwidth_*
function, not that of the read or write function of the device that
called it; this means you can't tell what device is involved.
The second is wrong because the offset is an offset into the device
but we use it as an absolute physical address, so we will access
whatever is at low memory. That happens to be the boot ROM, so we
will ignore a write and return random garbage on a read. This bug
has been present since 2011, when we did the conversions to the
MemoryRegion APIs, which involved changing all devices from working
with absolute physical addresses to working with offsets within their
MemoryRegions. We must have missed updating these functions.
Replace the uses of the omap_badwidth_read* functions in omap1.c with
an open-coded call to qemu_log_mask() and RAZ/WI behaviour.
We do just the reads here because there are a lot of callsites in
omap1.c; the writes will be done in the next commit.
Signed-off-by: Peter Maydell <[email protected]>
Reviewed-by: Philippe Mathieu-Daudé <[email protected]>
Commit: 7c1a339bbfc83c1d291496d7107be17591d70e5a
https://github.com/qemu/qemu/commit/7c1a339bbfc83c1d291496d7107be17591d70e5a
Author: Peter Maydell <[email protected]>
Date: 2026-01-15 (Thu, 15 Jan 2026)
Changed paths:
M hw/arm/omap1.c
Log Message:
-----------
hw/arm/omap1: Remove omap_badwidth_write* calls
Complete the conversion started in the previous commit by
changing all the omap_badwidth_write* calls to open-coded
log-and-ignore behaviour.
We can delete a FIXME comment about an infinite loop, because that
only looped infinitely back before 2011 when the device was still
using absolute physical addresses. Now that we are simply logging
the error we can clearly see that there's no loop.
Signed-off-by: Peter Maydell <[email protected]>
Reviewed-by: Philippe Mathieu-Daudé <[email protected]>
Commit: d751921cffd89756264b660b103adb277591ee06
https://github.com/qemu/qemu/commit/d751921cffd89756264b660b103adb277591ee06
Author: Peter Maydell <[email protected]>
Date: 2026-01-15 (Thu, 15 Jan 2026)
Changed paths:
M hw/arm/omap1.c
M include/hw/arm/omap.h
Log Message:
-----------
hw/arm/omap1: Remove omap_badwidth_* implementations
Now there are no callsites for the omap_badwidth_* family
of functions we can remove their implementations.
Signed-off-by: Peter Maydell <[email protected]>
Reviewed-by: Philippe Mathieu-Daudé <[email protected]>
Commit: 53b54a82520f23da2be49cc0d69210a086fc7072
https://github.com/qemu/qemu/commit/53b54a82520f23da2be49cc0d69210a086fc7072
Author: Pierrick Bouvier <[email protected]>
Date: 2026-01-15 (Thu, 15 Jan 2026)
Changed paths:
M hw/arm/sbsa-ref.c
M hw/arm/smmu-common.c
M hw/arm/virt.c
M include/hw/arm/smmu-common.h
M include/hw/arm/virt.h
Log Message:
-----------
hw/arm/smmu: add memory regions as property for an SMMU instance
This will be used to access non-secure and secure memory. Secure support
and Granule Protection Check (for RME) for SMMU need to access secure
memory.
As well, it allows to remove usage of global address_space_memory,
allowing different SMMU instances to have a specific view of memory.
User creatable SMMU are handled as well for virt machine,
by setting the memory properties when device is plugged in.
Reviewed-by: Philippe Mathieu-Daudé <[email protected]>
Signed-off-by: Pierrick Bouvier <[email protected]>
Reviewed-by: Eric Auger <[email protected]>
Message-id: [email protected]
Signed-off-by: Peter Maydell <[email protected]>
Commit: 1e812f8eb17f528d50843d94efce24a158ff1b4e
https://github.com/qemu/qemu/commit/1e812f8eb17f528d50843d94efce24a158ff1b4e
Author: Peter Maydell <[email protected]>
Date: 2026-01-15 (Thu, 15 Jan 2026)
Changed paths:
M docs/system/generic-loader.rst
Log Message:
-----------
docs/system/generic-loader: Clarify behaviour of cpu-num
The cpu-num suboption to the generic loader has two effects when
it is used with -device loader,file=<file>:
* it specifies which CPU to load the data through
* it specifies which CPU gets its PC set to the file's entry point
Our documentation is not very clear about what happens if you don't
pass this suboption. The default is that we pick the first CPU to
load the data, but we don't set the PC for any CPU, so the "If not
specified, the default is CPU 0" is confusing: it applies for loading
but not for the PC setting.
Clarify the text to make it clearer that the option has two effects
and the default behaviour is different for the two effects.
Signed-off-by: Peter Maydell <[email protected]>
Reviewed-by: Alex Bennée <[email protected]>
Commit: 5f8d9334076c4aa00dd9eb748a2d52c270f5824e
https://github.com/qemu/qemu/commit/5f8d9334076c4aa00dd9eb748a2d52c270f5824e
Author: Peter Maydell <[email protected]>
Date: 2026-01-15 (Thu, 15 Jan 2026)
Changed paths:
M docs/system/generic-loader.rst
Log Message:
-----------
docs/system/generic-loader: Don't mention QemuOpts implementation detail
We currently say "All values are parsed using the standard QemuOpts
parsing". This doesn't tell the user anything useful because we
don't mention QemuOpts anywhere else in the docs. What we're really
trying to tell the user is what we mention afterwards: that the
values are decimal, and you need an 0x prefix for hex. How we
achieve it is an implementation detail the user doesn't need to know.
Drop the explicit mention of QemuOpts; this in passing removes a typo
"QemuOps" that we made in one place. Put the informative note
more closely associated with the <addr> suboption which is the
one that users might most reasonably assume to default to hex.
Signed-off-by: Peter Maydell <[email protected]>
Reviewed-by: Alex Bennée <[email protected]>
Commit: 6b65590f4a47a8a36697ffde29e035a653c245c9
https://github.com/qemu/qemu/commit/6b65590f4a47a8a36697ffde29e035a653c245c9
Author: Peter Maydell <[email protected]>
Date: 2026-01-15 (Thu, 15 Jan 2026)
Changed paths:
M docs/system/generic-loader.rst
M hw/core/generic-loader.c
Log Message:
-----------
docs/system/generic-loader: move TODO to source code
Currently we have a "Restrictions and ToDos" section at the bottom of
the document which notes that there's no way to specify a CPU to load
a file through that doesn't also set that CPU's PC. This is written
as a developer-facing note. Move this to a TODO comment in the
source code, and provide a shorter user-facing statement of the
current restriction under the specific sub-option that it applies to.
Signed-off-by: Peter Maydell <[email protected]>
Reviewed-by: Alex Bennée <[email protected]>
Commit: 7cf096d609e67fd06abf6a59e592cb6de427825c
https://github.com/qemu/qemu/commit/7cf096d609e67fd06abf6a59e592cb6de427825c
Author: Alex Bennée <[email protected]>
Date: 2026-01-15 (Thu, 15 Jan 2026)
Changed paths:
M tests/functional/arm/test_aspeed_rainier.py
Log Message:
-----------
tests/functional: migrate aspeed_rainier image
Cedric has a host for the file which allows us to keep the name.
Cc: [email protected]
Signed-off-by: Alex Bennée <[email protected]>
Reviewed-by: Cédric Le Goater <[email protected]>
Message-id: [email protected]
Cc: Cédric Le Goater <[email protected]>
Signed-off-by: Peter Maydell <[email protected]>
Commit: 8da52b8401afa34ea8caa58e1bfb321ae142899b
https://github.com/qemu/qemu/commit/8da52b8401afa34ea8caa58e1bfb321ae142899b
Author: Peter Maydell <[email protected]>
Date: 2026-01-15 (Thu, 15 Jan 2026)
Changed paths:
M target/arm/helper.c
Log Message:
-----------
target/arm: Don't specify ID_PFR1 accessfn twice
In the definition of ID_PFR1 we have an ifdef block; we specify the
accessfn once in the common part of the ifdef and once in the
not-user-only part, which is redundant but harmless.
The accessfn will always return success in user-only mode (because
we won't trap to EL2), so specify it only in the not-user-only
half of the ifdef, as was probably the intention.
This is only cc'd to stable to avoid a textual conflict with
the following patch, which is a bug fix.
Cc: [email protected]
Fixes: 0f150c8499e970bd ("target/arm: Constify ID_PFR1 on user emulation")
Signed-off-by: Peter Maydell <[email protected]>
Reviewed-by: Alex Bennée <[email protected]>
Reviewed-by: Richard Henderson <[email protected]>
Message-id: [email protected]
Commit: 205ca535abaceda375c54797b1129a54a5ebbe96
https://github.com/qemu/qemu/commit/205ca535abaceda375c54797b1129a54a5ebbe96
Author: Peter Maydell <[email protected]>
Date: 2026-01-15 (Thu, 15 Jan 2026)
Changed paths:
M target/arm/helper.c
Log Message:
-----------
target/arm: Correctly honour HCR.TID3 for v7A cores
The HCR.TID3 bit defines that we should trap to the hypervisor for
reads to a collection of ID registers. Different architecture versions
have defined this differently:
* v7A has a set of ID regs that definitely must trap:
- ID_PFR{0,1}, ID_DFR0, ID_AFR0, ID_MMFR{0,1,2,3},
ID_ISAR{0,1,2,3,4,5}, MVFR{0,1}
and somewhat vaguely says that "there is no requirement"
to trap for registers that are reserved in the ID reg space
(i.e. which RAZ and might be used for new ID regs in future)
* v8A adds to this list:
- ID_PFR2 and MVFR2 must trap
- ID_MMFR4, ID_MMFR5, ID_ISAR6, ID_DFR1 and reserved registers
in the ID reg space must trap if FEAT_FGT is implemented,
and it is IMPDEF if they trap if FEAT_FGT is not implemented
In QEMU we seem to have attempted to implement this distinction
(taking the "we do trap" IMPDEF choice if no FEAT_FGT), with
access_aa64_tid3() always trapping on TID3 and access_aa32_tid3()
trapping only if ARM_FEATURE_V8 is set. However, we didn't apply
these to the right set of registers: we use access_aa32_tid3() on all
the 32-bit ID registers *except* ID_PFR2, ID_DFR1, ID_MMFR5 and the
RES0 space, which means that for a v7 CPU we don't trap on a lot of
registers that we should trap on, and we do trap on various things
that the v7A Arm ARM says there is "no requirement" to trap on.
Straighten this out by naming the access functions more clearly for
their purpose, and documenting this: access_v7_tid3() is only for the
fixed set of ID registers that v7A traps on HCR.TID3, and
access_tid3() is for any others, including the reserved encoding
spaces and any new registers we add in future.
AArch32 MVFR2 access is handled differently, in check_hcr_el2_trap;
there we already do not trap on TID3 on v7A cores (where MVFR2
doesn't exist), because we in the code-generation function we UNDEF
if ARM_FEATURE_V8 is not set, without generating code to call
check_hcr_el2_trap.
This bug was causing a problem for Xen which (after a recent change
to Xen) expects to be able to trap ID_PFR0 on a Cortex-A15.
The result of these changes is that our v8A behaviour remains
the same, and on v7A we now trap the registers the Arm ARM definitely
requires us to trap, and don't trap the reserved space that "there is
no requirement" to trap.
Cc: [email protected]
Fixes: 6a4ef4e5d1084c ("target/arm: Honor HCR_EL2.TID3 trapping requirements")
Signed-off-by: Peter Maydell <[email protected]>
Reviewed-by: Alex Bennée <[email protected]>
Reviewed-by: Richard Henderson <[email protected]>
Message-id: [email protected]
Commit: b67a35622f9a816544ec094132d8af0debfac7f2
https://github.com/qemu/qemu/commit/b67a35622f9a816544ec094132d8af0debfac7f2
Author: Peter Maydell <[email protected]>
Date: 2026-01-15 (Thu, 15 Jan 2026)
Changed paths:
M target/arm/helper.c
Log Message:
-----------
target/arm: Correctly trap HCR.TID1 registers in v7A
In v7A HCR.TID1 is defined to trap for TCMTR, TLBTR, REVIDR and AIDR.
We incorrectly use an accessfn for REVIDR and AIDR that only traps on
v8A cores. Fix this by collapsing access_aa64_tid1() and
access_aa32_tid1() together and never doing a check for v8 vs v7.
The accessfn is also used for SMIDR_EL1, which is fine as this
register is AArch64 only.
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]
Commit: 4efed64ffcdb99b977ad0b2129a9c0208456a6c9
https://github.com/qemu/qemu/commit/4efed64ffcdb99b977ad0b2129a9c0208456a6c9
Author: Peter Maydell <[email protected]>
Date: 2026-01-15 (Thu, 15 Jan 2026)
Changed paths:
M target/arm/helper.c
Log Message:
-----------
target/arm: Rename access_aa64_tid5() to access_tid5()
There is no equivalent access_aa32_tid5() (HCR_EL2.TID5 only exists
starting from v8); rename access_aa64_tid5() to access_tid5() to line
up with the naming we now have for the TID1 and TID3 check functions.
Signed-off-by: Peter Maydell <[email protected]>
Reviewed-by: Alex Bennée <[email protected]>
Reviewed-by: Richard Henderson <[email protected]>
Message-id: [email protected]
Commit: beaeffb57c3358d24abf02ee4e8f6412d55aa1e5
https://github.com/qemu/qemu/commit/beaeffb57c3358d24abf02ee4e8f6412d55aa1e5
Author: Richard Henderson <[email protected]>
Date: 2026-01-16 (Fri, 16 Jan 2026)
Changed paths:
M hw/loongarch/virt-fdt-build.c
M hw/loongarch/virt.c
M target/loongarch/tcg/tcg_cpu.c
Log Message:
-----------
Merge tag 'pull-loongarch-20260115' of https://github.com/bibo-mao/qemu into
staging
loongarch queue
# -----BEGIN PGP SIGNATURE-----
#
# iHUEABYKAB0WIQQNhkKjomWfgLCz0aQfewwSUazn0QUCaWiLIAAKCRAfewwSUazn
# 0cGHAQCVjRn2wPtniAIS6HQ/edTPXQt8Nr83Bv6SHkcOskbexwEA/OmUd4MiftSV
# GJFfJ66Z3i9TCRZJdLqsUZBk9p9W9AQ=
# =Aiem
# -----END PGP SIGNATURE-----
# gpg: Signature made Thu 15 Jan 2026 05:37:20 PM AEDT
# gpg: using EDDSA key 0D8642A3A2659F80B0B3D1A41F7B0C1251ACE7D1
# gpg: Good signature from "bibo mao <[email protected]>" [unknown]
# gpg: WARNING: This key is not certified with a trusted signature!
# gpg: There is no indication that the signature belongs to the owner.
# Primary key fingerprint: 7044 3A00 19C0 E97A 31C7 13C4 8E86 8FB7 A176 9D4C
# Subkey fingerprint: 0D86 42A3 A265 9F80 B0B3 D1A4 1F7B 0C12 51AC E7D1
* tag 'pull-loongarch-20260115' of https://github.com/bibo-mao/qemu:
hw/loongarch/virt: Don't abort on access to unimplemented IOCSR
target/loongarch: Fix exception ADEF/ADEM missing to update CSR_BADV
target/loongarch: Fix exception BCE missing to update CSR_BADV
target/loongach: Fix some exceptions failure in updating CSR_BADV
hw/loongarch/virt: Fix irq allocation failure with pci device from fdt
hw/loongarch/virt: Modify the interrupt trigger type in fdt table
Signed-off-by: Richard Henderson <[email protected]>
Commit: c1c58cee16380f81f88fbde6b12f247b376839e2
https://github.com/qemu/qemu/commit/c1c58cee16380f81f88fbde6b12f247b376839e2
Author: Richard Henderson <[email protected]>
Date: 2026-01-16 (Fri, 16 Jan 2026)
Changed paths:
M docs/system/arm/emulation.rst
M docs/system/generic-loader.rst
M hw/arm/max78000fthr.c
M hw/arm/omap1.c
M hw/arm/raspi.c
M hw/arm/sbsa-ref.c
M hw/arm/smmu-common.c
M hw/arm/virt.c
M hw/char/cmsdk-apb-uart.c
M hw/core/generic-loader.c
M hw/dma/omap_dma.c
M hw/gpio/omap_gpio.c
M hw/i2c/omap_i2c.c
M hw/sd/omap_mmc.c
A include/hw/arm/arm-security.h
M include/hw/arm/omap.h
M include/hw/arm/smmu-common.h
M include/hw/arm/virt.h
M target/arm/cpu-features.h
M target/arm/cpu-sysregs.h.inc
M target/arm/cpu.h
M target/arm/helper.c
M target/arm/internals.h
M target/arm/ptw.c
M target/arm/tcg/cpu64.c
M tests/functional/arm/test_aspeed_rainier.py
A tests/tcg/aarch64/system/asid2.c
Log Message:
-----------
Merge tag 'pull-target-arm-20260115' of https://gitlab.com/pm215/qemu into
staging
target-arm queue:
* hw/arm/raspi: remove duplicate include
* target/arm: Enable FEAT_ASID2 emulation
* hw/char/cmsdk-apb-uart.c: log guest_errors for r/w to disabled uart
* hw/arm: Re-enable the MAX78000FTHR machine in qemu-system-arm/aarch64
* target/arm/ptw: make granule_protection_check usable without a cpu
* hw/arm/omap: Remove omap_badwidth_* functions
* hw/arm/smmu: add memory regions as property for an SMMU instance
* docs/system/generic-loader: clarify
* tests/functional: migrate aspeed_rainier image
* target/arm: Correctly handle HCR.TID1 and TID3 traps on v7A CPUs
# -----BEGIN PGP SIGNATURE-----
#
# iQJNBAABCAA3FiEE4aXFk81BneKOgxXPPCUl7RQ2DN4FAmlpN5EZHHBldGVyLm1h
# eWRlbGxAbGluYXJvLm9yZwAKCRA8JSXtFDYM3j/QD/9G1AV5Sd59zoO//cS6m7OO
# dB0/1MaX7ChTK4zHaQwA2TammwKTxUDV1nj8LJBd4/d1SV1SC3OrYl88bQdjKhLD
# +o4z9snfV+TmVm6WlmKvDkOhV0UdhrA31exvXFOXytmVSq6BxvHv/yy2j4eo8KVu
# UtWf8A2RHnfR1QNIvBGtDQ7NWhd9XHV8mKtGMIiTTQtQ72/9MLig9Kbv97yavbRT
# ZY8AdvDZJrR8P7euRc//qmGuWb6ix2GiFRWQ0FXQu/qU63MR+Css12nzkXFFGeU2
# KEtZ2PTwd8i/NRYtJmqVw3ZsQHAqXplGle/VzK7orTLWKHbjiLOc9FdnSVplkBNM
# AWhQGVqrwXYHnEI34RiTQuxzhNepPwOgS6/0gXw2mHzHQ5g6ndZnfJuPTw/70ZNY
# Yd0nAU1ajvgW/1/i9zVs4aQ5wy/SFRd+OoHqujVIcKWB9iPWvNZUGgrnySQO8lq+
# 6GOMZauK+8kU4WJO/wHCW9ktIUPWjwYmmTLwElTj/VUEjShy2t8mETZEvzJl+eVl
# WZpzfJEvbraJiCe+e2QRcRA0goTlBdNneUQ31ePoVOpXS6UXIXuqd3Qisli9y4sB
# 9NrJseIQ7RclIYfpHxkrlejXGOFlwtxaDoxSupn7IblKCCFFf6TS3LwiJRXpcf2k
# kpMq6Mcnt/HCrpvmN5gNUA==
# =yMo2
# -----END PGP SIGNATURE-----
# gpg: Signature made Fri 16 Jan 2026 05:53:05 AM AEDT
# gpg: using RSA key E1A5C593CD419DE28E8315CF3C2525ED14360CDE
# gpg: issuer "[email protected]"
# gpg: Good signature from "Peter Maydell <[email protected]>" [unknown]
# gpg: aka "Peter Maydell <[email protected]>" [unknown]
# gpg: aka "Peter Maydell <[email protected]>"
[unknown]
# gpg: aka "Peter Maydell <[email protected]>" [unknown]
# gpg: WARNING: The key's User ID is not certified with a trusted signature!
# gpg: There is no indication that the signature belongs to the owner.
# Primary key fingerprint: E1A5 C593 CD41 9DE2 8E83 15CF 3C25 25ED 1436 0CDE
* tag 'pull-target-arm-20260115' of https://gitlab.com/pm215/qemu: (25 commits)
target/arm: Rename access_aa64_tid5() to access_tid5()
target/arm: Correctly trap HCR.TID1 registers in v7A
target/arm: Correctly honour HCR.TID3 for v7A cores
target/arm: Don't specify ID_PFR1 accessfn twice
tests/functional: migrate aspeed_rainier image
docs/system/generic-loader: move TODO to source code
docs/system/generic-loader: Don't mention QemuOpts implementation detail
docs/system/generic-loader: Clarify behaviour of cpu-num
hw/arm/smmu: add memory regions as property for an SMMU instance
hw/arm/omap1: Remove omap_badwidth_* implementations
hw/arm/omap1: Remove omap_badwidth_write* calls
hw/arm/omap1: Remove omap_badwidth_read* calls
hw/dma/omap_dma: Remove omap_badwidth_* calls
hw/gpio/omap_gpio: Remove omap_badwidth_* calls
hw/i2c/omap_i2c: Remove omap_badwidth_* calls
hw/sd/omap_mmc: Remove omap_badwidth_* calls
target/arm/ptw: make granule_protection_check usable without a cpu
target/arm: Move ARMSecuritySpace to a common header
hw/arm: Re-enable the MAX78000FTHR machine in qemu-system-arm/aarch64
hw/char/cmsdk-apb-uart.c: log guest_errors for r/w to disabled uart
...
Signed-off-by: Richard Henderson <[email protected]>
Compare: https://github.com/qemu/qemu/compare/4cfa1ce0365f...c1c58cee1638
To unsubscribe from these emails, change your notification settings at
https://github.com/qemu/qemu/settings/notifications
