hw/misc: Add an iBT device model

Implement an IPMI BT interface model using a chardev backend to
communicate with an external PowerNV machine. It uses the OpenIPMI
simulator protocol for virtual mac

hw/misc: Add an iBT device model

Implement an IPMI BT interface model using a chardev backend to
communicate with an external PowerNV machine. It uses the OpenIPMI
simulator protocol for virtual machines described in :

https://github.com/cminyard/openipmi/blob/master/lanserv/README.vm

and implemented by the 'ipmi-bmc-extern' model on the host side.

To use, start the Aspeed BMC machine with :

-chardev socket,id=ipmi0,host=localhost,port=9002,ipv4,server,nowait \
-global driver=aspeed.ibt,property=chardev,value=ipmi0

and the PowerNV machine with :

-chardev socket,id=ipmi0,host=localhost,port=9002,reconnect=10 \
-device ipmi-bmc-extern,id=bmc0,chardev=ipmi0 \
-device isa-ipmi-bt,bmc=bmc0,irq=10 -nodefaults

Cc: Hao Wu <wuhaotsh@google.com>
Cc: Corey Minyard <cminyard@mvista.com>
Reviewed-by: Joel Stanley <joel@jms.id.au>
Signed-off-by: Cédric Le Goater <clg@kaod.org>

show more ...

hw/misc: Add basic Aspeed PWM model

Just enough to quiet down the output when running with the logs.

Signed-off-by: Cédric Le Goater <clg@kaod.org>

hw/misc: Add basic Aspeed GFX model

Enough model to capture the pinmux writes to enable correct operation of
the parts of pinmux that depend on GFX registers.

Signed-off-by: Joel Stanley <joel@jms.

hw/misc: Add basic Aspeed GFX model

Enough model to capture the pinmux writes to enable correct operation of
the parts of pinmux that depend on GFX registers.

Signed-off-by: Joel Stanley <joel@jms.id.au>

show more ...

hw/misc/aspeed_i3c: Move to i3c directory

Moves the Aspeed I3C model and traces into hw/i3c and creates I3C build
files.

Signed-off-by: Joe Komlodi <komlodi@google.com>

Reviewed-by: Patrick Ventur

hw/misc/aspeed_i3c: Move to i3c directory

Moves the Aspeed I3C model and traces into hw/i3c and creates I3C build
files.

Signed-off-by: Joe Komlodi <komlodi@google.com>

Reviewed-by: Patrick Venture <venture@google.com>
Reviewed-by: Titus Rwantare <titusr@google.com>
Reviewed-by: Cédric Le Goater <clg@redhat.com>
Link: https://lore.kernel.org/qemu-devel/20250613000411.1516521-2-komlodi@google.com
Signed-off-by: Cédric Le Goater <clg@redhat.com>

show more ...

hw/arm/aspeed_ast27x0: Introduce 3 PCIe RCs for AST2700

Add PCIe Root Complex support to the AST2700 SoC model.

The AST2700 A1 silicon revision provides three PCIe Root Complexes:

PCIe0 with its P

hw/arm/aspeed_ast27x0: Introduce 3 PCIe RCs for AST2700

Add PCIe Root Complex support to the AST2700 SoC model.

The AST2700 A1 silicon revision provides three PCIe Root Complexes:

PCIe0 with its PHY at 0x12C15000, config (H2X) block at 0x120E0000,
MMIO window at 0x60000000, and GIC IRQ 56.

PCIe1 with its PHY at 0x12C15800, config (H2X) block at 0x120F0000,
MMIO window at 0x80000000, and GIC IRQ 57.

PCIe2 with its PHY at 0x14C1C000, config (H2X) block at 0x140D0000,
MMIO window at 0xA0000000, and IRQ routed through INTC4 bit 31
mapped to GIC IRQ 196.

Each RC instantiates a PHY device, a PCIe config (H2X) bridge, and an MMIO
alias region. The per-RC MMIO alias size is 0x20000000. The AST2700 A0
silicon revision does not support PCIe Root Complexes, so pcie_num is set
to 0 in that variant.

Signed-off-by: Jamin Lin <jamin_lin@aspeedtech.com>
Link: https://lore.kernel.org/qemu-devel/20250819090141.3949136-11-jamin_lin@aspeedtech.com
Signed-off-by: Cédric Le Goater <clg@redhat.com>

show more ...

hw/arm/aspeed: Wire up PCIe devices in SoC model

Add PCIe controller and PHY instances to the Aspeed SoC state and device
enum. This prepares the SoC model to host PCIe Root Complexes and their
asso

hw/arm/aspeed: Wire up PCIe devices in SoC model

Add PCIe controller and PHY instances to the Aspeed SoC state and device
enum. This prepares the SoC model to host PCIe Root Complexes and their
associated PHYs.

Although the AST2600 supports only a single Root Complex, the AST2700
provides three Root Complexes. For this reason, the model defines arrays
of three PCIe config/PHY objects and enumerates three PCIe device IDs so
that both SoCs can be represented consistently.

Signed-off-by: Jamin Lin <jamin_lin@aspeedtech.com>
Link: https://lore.kernel.org/qemu-devel/20250819090141.3949136-6-jamin_lin@aspeedtech.com
Signed-off-by: Cédric Le Goater <clg@redhat.com>

show more ...

hw/arm/ast27x0: Add DRAM alias for TSP SDRAM remap and update realization order

This commit adds a MemoryRegion alias to support PSP access to
TSP SDRAM through shared memory remapping, as defined b

hw/arm/ast27x0: Add DRAM alias for TSP SDRAM remap and update realization order

This commit adds a MemoryRegion alias to support PSP access to
TSP SDRAM through shared memory remapping, as defined by the default SCU
configuration.

The TSP coprocessor exposes one DRAM alias:
- remap maps PSP DRAM at 0x42e000000 (32MB) to TSP SDRAM offset 0x0

This region corresponds to the default SCU register value, which controls
the mapping between PSP and coprocessor memory windows.

To ensure correctness, the alias is initialized early in
aspeed_soc_ast2700_realize(), before SCU and coprocessor realization.
This allows TSP to reference the alias region during its SDRAM setup.

Signed-off-by: Jamin Lin <jamin_lin@aspeedtech.com>
Link: https://lore.kernel.org/qemu-devel/20250717034054.1903991-13-jamin_lin@aspeedtech.com
Signed-off-by: Cédric Le Goater <clg@redhat.com>

show more ...

hw/arm/ast27x0: Add DRAM alias for SSP SDRAM remap and update realization order

This commit adds two MemoryRegion aliases to support PSP access to
SSP SDRAM through shared memory remapping, as defin

hw/arm/ast27x0: Add DRAM alias for SSP SDRAM remap and update realization order

This commit adds two MemoryRegion aliases to support PSP access to
SSP SDRAM through shared memory remapping, as defined by the default SCU
configuration.

The SSP coprocessor exposes two DRAM aliases:
- remap1 maps PSP DRAM at 0x400000000 (32MB) to SSP SDRAM offset 0x2000000
- remap2 maps PSP DRAM at 0x42c000000 (32MB) to SSP SDRAM offset 0x0

These regions correspond to the default SCU register values, which control
the mapping between PSP and coprocessor memory windows.

To ensure correctness, the aliases are initialized early in
aspeed_soc_ast2700_realize(), before SCU and coprocessor realization.
This allows SSP to reference the alias regions during its SDRAM setup.

Additionally, the realization order comment has been updated to reflect
the new DRAM dependency: coprocessors must now be realized after DRAM,
SRAM, and SCU are all initialized.

Signed-off-by: Jamin Lin <jamin_lin@aspeedtech.com>
Link: https://lore.kernel.org/qemu-devel/20250717034054.1903991-12-jamin_lin@aspeedtech.com
Signed-off-by: Cédric Le Goater <clg@redhat.com>

show more ...

hw/arm/ast27x0: Add SCU alias for TSP and ensure correct device realization order

AST2700 has a single SCU hardware block, memory-mapped at 0x12C02000–0x12C03FFF
from the perspective of the main CA3

hw/arm/ast27x0: Add SCU alias for TSP and ensure correct device realization order

AST2700 has a single SCU hardware block, memory-mapped at 0x12C02000–0x12C03FFF
from the perspective of the main CA35 processor (PSP). The TSP coprocessor accesses
this same SCU block at a different address: 0x72C02000–0x72C03FFF.

To support this shared SCU model, this commit introduces "tsp.scu_mr_alias",
a "MemoryRegion" alias of the original SCU region ("s->scu.iomem"). The alias is
realized during TSP SoC setup and mapped into the TSP's SoC memory map.

Additionally, because the SCU must be realized before the TSP can create an alias
to it, the device realization order is explicitly managed:
"aspeed_soc_ast2700_tsp_realize()" is invoked after the SCU is initialized.

This ensures that PSP and TSP access a consistent SCU state, as expected by hardware.

Signed-off-by: Jamin Lin <jamin_lin@aspeedtech.com>
Link: https://lore.kernel.org/qemu-devel/20250717034054.1903991-10-jamin_lin@aspeedtech.com
Signed-off-by: Cédric Le Goater <clg@redhat.com>

show more ...

hw/arm/ast27x0: Add SCU alias for SSP and ensure correct device realization order

AST2700 has a single SCU hardware block, memory-mapped at 0x12C02000–0x12C03FFF
from the perspective of the main CA3

hw/arm/ast27x0: Add SCU alias for SSP and ensure correct device realization order

AST2700 has a single SCU hardware block, memory-mapped at 0x12C02000–0x12C03FFF
from the perspective of the main CA35 processor (PSP). The SSP coprocessor accesses
this same SCU block at a different address: 0x72C02000–0x72C03FFF.

To support this shared SCU model, this commit introduces "ssp.scu_mr_alias",
a "MemoryRegion" alias of the original SCU region ("s->scu.iomem"). The alias is
realized during SSP SoC setup and mapped into the SSP's SoC memory map.

Additionally, because the SCU must be realized before the SSP can create an alias
to it, the device realization order is explicitly managed:
"aspeed_soc_ast2700_ssp_realize()" is invoked after the SCU is initialized.

This ensures that PSP and SSP access a consistent SCU state, as expected by hardware.

Signed-off-by: Jamin Lin <jamin_lin@aspeedtech.com>
Link: https://lore.kernel.org/qemu-devel/20250717034054.1903991-9-jamin_lin@aspeedtech.com
Signed-off-by: Cédric Le Goater <clg@redhat.com>

show more ...

hw/arm/ast27x0: Add SRAM alias for TSP and ensure correct device realization order

AST2700 has a 128KB SRAM, physically mapped at 0x10000000–0x1001FFFF for the
main CA35 processor. The TSP coprocess

hw/arm/ast27x0: Add SRAM alias for TSP and ensure correct device realization order

AST2700 has a 128KB SRAM, physically mapped at 0x10000000–0x1001FFFF for the
main CA35 processor. The TSP coprocessor accesses this same memory at a
different memory address: 0x70000000–0x7001FFFF.

To support this shared memory model, this commit introduces "tsp.sram_mr_alias",
a "MemoryRegion" alias of the original SRAM region ("s->sram"). The alias is
realized during TSP SoC setup and mapped into the TSP's SoC memory map.

Additionally, because the SRAM must be realized before the TSP can create an
alias to it, the device realization order is explicitly managed:
"aspeed_soc_ast2700_tsp_realize()" is invoked after SRAM is initialized.

This ensures that TSP’s access to shared SRAM functions correctly.

Signed-off-by: Jamin Lin <jamin_lin@aspeedtech.com>
Link: https://lore.kernel.org/qemu-devel/20250717034054.1903991-8-jamin_lin@aspeedtech.com
Signed-off-by: Cédric Le Goater <clg@redhat.com>

show more ...

hw/arm/ast27x0: Add SRAM alias for SSP and ensure correct device realization order

AST2700 has a 128KB SRAM, physically mapped at 0x10000000–0x1001FFFF for the
main CA35 processor. The SSP coprocess

hw/arm/ast27x0: Add SRAM alias for SSP and ensure correct device realization order

AST2700 has a 128KB SRAM, physically mapped at 0x10000000–0x1001FFFF for the
main CA35 processor. The SSP coprocessor accesses this same memory at a
different memory address: 0x70000000–0x7001FFFF.

To support this shared memory model, this commit introduces "ssp.sram_mr_alias",
a "MemoryRegion" alias of the original SRAM region ("s->sram"). The alias is
realized during SSP SoC setup and mapped into the SSP's SoC memory map.

Additionally, because the SRAM must be realized before the SSP can create an
alias to it, the device realization order is explicitly managed:
"aspeed_soc_ast2700_ssp_realize()" is invoked after SRAM is initialized.

This ensures that SSP’s access to shared SRAM functions correctly.

Signed-off-by: Jamin Lin <jamin_lin@aspeedtech.com>
Link: https://lore.kernel.org/qemu-devel/20250717034054.1903991-7-jamin_lin@aspeedtech.com
Signed-off-by: Cédric Le Goater <clg@redhat.com>

show more ...

hw/arm/ast27x0: Move TSP coprocessor initialization from machine to SoC leve

In the previous design, the TSP coprocessor (aspeed27x0tsp-soc) was initialized
and realized at the machine level (e.g.,

hw/arm/ast27x0: Move TSP coprocessor initialization from machine to SoC leve

In the previous design, the TSP coprocessor (aspeed27x0tsp-soc) was initialized
and realized at the machine level (e.g., AST2700FC). To allow proper
integration between coprocessors—such as shared use of SRAM, SCU, and memory
remap configuration—this commit moves TSP initialization into the AST2700 SoC.

By handling TSP initialization and realization at the SoC level, it becomes
easier to manage device ordering and ensure correct dependencies between
coprocessors and controllers. It also reflects the hardware design more
accurately, as these processors belong to the SoC, not the board.

Benefits of this change:
- TSP can share SCU, SRAM, and memory regions with other SoC devices.
- Centralizes coprocessor setup logic under SoC for better maintenance.
- Simplifies machine-level code in "aspeed_ast27x0-fc.c".

This is part of ongoing work to support shared SCU, SRAM, and memory remap
handling across PSP, SSP, and TSP. Future commits will add memory remap
mechanisms and tightly integrated SoC controller coordination.

Signed-off-by: Jamin Lin <jamin_lin@aspeedtech.com>
Link: https://lore.kernel.org/qemu-devel/20250717034054.1903991-4-jamin_lin@aspeedtech.com
Signed-off-by: Cédric Le Goater <clg@redhat.com>

show more ...

hw/arm/ast27x0: Move SSP coprocessor initialization from machine to SoC leve

In the previous design, the SSP coprocessor (aspeed27x0ssp-soc) was initialized
and realized at the machine level (e.g.,

hw/arm/ast27x0: Move SSP coprocessor initialization from machine to SoC leve

In the previous design, the SSP coprocessor (aspeed27x0ssp-soc) was initialized
and realized at the machine level (e.g., AST2700FC). However, to make sure the
coprocessors can work together properly—such as using the same SRAM, sharing
the SCU, and having consistent memory remapping—we need to change how these
devices are set up.

This commit moves the SSP coprocessor initialization and realization into the
AST2700 SoC (aspeed_soc_ast2700_init() and aspeed_soc_ast2700_realize()).
By doing so, the SSP becomes a proper child of the SoC device, rather than
the machine.

This is a preparation step for future commits that will support shared SCU,
SRAM, and memory remap logic—specifically enabling PSP DRAM remap for SSP SDRAM
access.

Signed-off-by: Jamin Lin <jamin_lin@aspeedtech.com>
Link: https://lore.kernel.org/qemu-devel/20250717034054.1903991-3-jamin_lin@aspeedtech.com
Signed-off-by: Cédric Le Goater <clg@redhat.com>

show more ...

hw/arm/stm32f205_soc: Don't leak TYPE_OR_IRQ objects

In stm32f250_soc_initfn() we mostly use the standard pattern
for child objects of calling object_initialize_child(). However
for s->adc_irqs we c

hw/arm/stm32f205_soc: Don't leak TYPE_OR_IRQ objects

In stm32f250_soc_initfn() we mostly use the standard pattern
for child objects of calling object_initialize_child(). However
for s->adc_irqs we call object_new() and then later qdev_realize(),
and we never unref the object on deinit. This causes a leak,
detected by ASAN on the device-introspect-test:

Indirect leak of 10 byte(s) in 1 object(s) allocated from:
#0 0x5b9fc4789de3 in malloc (/mnt/nvmedisk/linaro/qemu-from-laptop/qemu/build/arm-asan/qemu-system-arm+0x21f1de3) (BuildId: 267a2619a026ed91c78a07b1eb2ef15381538efe)
#1 0x740de3f28b09 in g_malloc (/lib/x86_64-linux-gnu/libglib-2.0.so.0+0x62b09) (BuildId: 1eb6131419edb83b2178b682829a6913cf682d75)
#2 0x740de3f3e4d8 in g_strdup (/lib/x86_64-linux-gnu/libglib-2.0.so.0+0x784d8) (BuildId: 1eb6131419edb83b2178b682829a6913cf682d75)
#3 0x5b9fc70159e1 in g_strdup_inline /usr/include/glib-2.0/glib/gstrfuncs.h:321:10
#4 0x5b9fc70159e1 in object_property_try_add /mnt/nvmedisk/linaro/qemu-from-laptop/qemu/build/arm-asan/../../qom/object.c:1276:18
#5 0x5b9fc7015f94 in object_property_add /mnt/nvmedisk/linaro/qemu-from-laptop/qemu/build/arm-asan/../../qom/object.c:1294:12
#6 0x5b9fc701b900 in object_add_link_prop /mnt/nvmedisk/linaro/qemu-from-laptop/qemu/build/arm-asan/../../qom/object.c:2021:10
#7 0x5b9fc701b3fc in object_property_add_link /mnt/nvmedisk/linaro/qemu-from-laptop/qemu/build/arm-asan/../../qom/object.c:2037:12
#8 0x5b9fc4c299fb in qdev_init_gpio_out_named /mnt/nvmedisk/linaro/qemu-from-laptop/qemu/build/arm-asan/../../hw/core/gpio.c:90:9
#9 0x5b9fc4c29b26 in qdev_init_gpio_out /mnt/nvmedisk/linaro/qemu-from-laptop/qemu/build/arm-asan/../../hw/core/gpio.c:101:5
#10 0x5b9fc4c0f77a in or_irq_init /mnt/nvmedisk/linaro/qemu-from-laptop/qemu/build/arm-asan/../../hw/core/or-irq.c:70:5
#11 0x5b9fc70257e1 in object_init_with_type /mnt/nvmedisk/linaro/qemu-from-laptop/qemu/build/arm-asan/../../qom/object.c:428:9
#12 0x5b9fc700cd4b in object_initialize_with_type /mnt/nvmedisk/linaro/qemu-from-laptop/qemu/build/arm-asan/../../qom/object.c:570:5
#13 0x5b9fc700e66d in object_new_with_type /mnt/nvmedisk/linaro/qemu-from-laptop/qemu/build/arm-asan/../../qom/object.c:774:5
#14 0x5b9fc700e750 in object_new /mnt/nvmedisk/linaro/qemu-from-laptop/qemu/build/arm-asan/../../qom/object.c:789:12
#15 0x5b9fc68b2162 in stm32f205_soc_initfn /mnt/nvmedisk/linaro/qemu-from-laptop/qemu/build/arm-asan/../../hw/arm/stm32f205_soc.c:69:26

Switch to using object_initialize_child() like all our
other child objects for this SoC object.

Cc: qemu-stable@nongnu.org
Fixes: b63041c8f6b ("STM32F205: Connect the ADC devices")
Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
Reviewed-by: Philippe Mathieu-Daudé <philmd@linaro.org>
Message-id: 20250821154229.2417453-1-peter.maydell@linaro.org
(cherry picked from commit 2e27650bddd35477d994a795a3b1cb57c8ed5c76)
Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>

show more ...

Merge tag 'accel-20250715' of https://github.com/philmd/qemu into staging

Accelerators patches

- Unify x86/arm hw/xen/arch_hvm.h header
- Move non-system-specific 'accel/accel-ops.h' and 'accel-cpu

Merge tag 'accel-20250715' of https://github.com/philmd/qemu into staging

Accelerators patches

- Unify x86/arm hw/xen/arch_hvm.h header
- Move non-system-specific 'accel/accel-ops.h' and 'accel-cpu-ops.h' to accel/
- Move KVM definitions qapi/accelerator.json
- Add @qom-type field to CpuInfoFast QAPI structure
- Display CPU model name in 'info cpus' HMP command
- Introduce @x-accel-stats QMP command
- Add 'info accel' on HMP
- Improve qemu_add_vm_change_state_handler*() docstring
- Extract TCG statistic related code to tcg-stats.c
- Implement AccelClass::get_[vcpu]_stats() handlers for TCG and HVF
- Do not dump NaN in TCG statistics
- Revert incomplete "accel/tcg: Unregister the RCU before exiting RR thread"

# -----BEGIN PGP SIGNATURE-----
#
# iQIzBAABCAAdFiEE+qvnXhKRciHc/Wuy4+MsLN6twN4FAmh2r4UACgkQ4+MsLN6t
# wN5i6xAAkOvwFh1GmsPUdz5RxzsWoIUDvyENg6E8Axwe5tSEMRFiPjabbTQJomQg
# GZt75XIS24LZFZ+hvqrLSA+dFgXTgWv08ZE81EjwjmAMBlLCOPhCgeN6C1p8100Y
# scSvRJbP9k9lpA5K7et/1X4AkK2cZyh+LGJgCjr2Al2mbERpPueDF8fxqeohFvXQ
# nTSks4XlA0yQ06+9r49aQAiuXvgg9lDT1wIglD2HEV7vOVs/ud+yyL8+z5YMeFzx
# pSIc6wDu4PqdA46w4MZs90uTy7S/PMvBiYDEiV3tKzg0MLttvFGlT58/YjVtguTP
# mNkfwIEwQtDQzoxsFIJO7yBTlTRBs95V4aIVk3pB+Gb/bideRPIkeVQvgMSEBKj7
# N0pEXWOxfB9iIWO6b1utYpQ4uxeDOU/8DPUCit1IBbNgKTaJkJb77fboYk7NaB0K
# KEtObAk6jMatB/xr+vUFWc4sMk9wlm72w8wcQzgKZ0xV2U3d1/Y/9nS4GvI510ev
# TRQ3mKj7N319uCeId1czF6W8rillCJ2u8ZK53u+Nfp7R3PbsRSMc6IDJ1UdDUlyR
# HFcWHxbcbEGhe8SnFGab4Qd6fWChcn2EaEoAJJz+Rqv0k3zcwqccNM5waCABAjTE
# 0S22JIHePJKcpkMLGq3EOUAQuu+8Zsol7gPCLxSAMclVqPTl9ck=
# =rAav
# -----END PGP SIGNATURE-----
# gpg: Signature made Tue 15 Jul 2025 15:44:05 EDT
# gpg: using RSA key FAABE75E12917221DCFD6BB2E3E32C2CDEADC0DE
# gpg: Good signature from "Philippe Mathieu-Daudé (F4BUG) <f4bug@amsat.org>" [full]
# Primary key fingerprint: FAAB E75E 1291 7221 DCFD 6BB2 E3E3 2C2C DEAD C0DE

* tag 'accel-20250715' of https://github.com/philmd/qemu:
system/runstate: Document qemu_add_vm_change_state_handler_prio* in hdr
system/runstate: Document qemu_add_vm_change_state_handler()
accel/hvf: Implement AccelClass::get_vcpu_stats() handler
accel/tcg: Implement AccelClass::get_stats() handler
accel/tcg: Propagate AccelState to dump_accel_info()
accel/system: Add 'info accel' on human monitor
accel/system: Introduce @x-accel-stats QMP command
accel/tcg: Extract statistic related code to tcg-stats.c
Revert "accel/tcg: Unregister the RCU before exiting RR thread"
accel: Extract AccelClass definition to 'accel/accel-ops.h'
accel: Rename 'system/accel-ops.h' -> 'accel/accel-cpu-ops.h'
accel/tcg: Do not dump NaN statistics
hw/core/machine: Display CPU model name in 'info cpus' command
qapi/machine: Add @qom-type field to CpuInfoFast structure
qapi/accel: Move definitions related to accelerators in their own file
hw/arm/xen-pvh: Remove unnecessary 'hw/xen/arch_hvm.h' header
hw/xen/arch_hvm: Unify x86 and ARM variants

Signed-off-by: Stefan Hajnoczi <stefanha@redhat.com>

Conflicts:
qapi/machine.json
Commit 0462da9d6b19 ("qapi: remove trivial "Returns:" sections")
removed trivial "Returns:". This caused a conflict with the move from
machine.json to accelerator.json.

show more ...

hw/xen/arch_hvm: Unify x86 and ARM variants

As each target declares the same prototypes, we can
use a single header, removing the TARGET_XXX uses.

Signed-off-by: Philippe Mathieu-Daudé <philmd@lina

hw/xen/arch_hvm: Unify x86 and ARM variants

As each target declares the same prototypes, we can
use a single header, removing the TARGET_XXX uses.

Signed-off-by: Philippe Mathieu-Daudé <philmd@linaro.org>
Reviewed-by: Pierrick Bouvier <pierrick.bouvier@linaro.org>
Reviewed-by: Stefano Stabellini <sstabellini@kernel.org>
Message-Id: <20250513171737.74386-1-philmd@linaro.org>

show more ...

hw/arm/virt-acpi-build: Modify the DSDT ACPI table to enable ACPI PCI hotplug

Modify the DSDT ACPI table to enable ACPI PCI hotplug.

Signed-off-by: Eric Auger <eric.auger@redhat.com>
Reviewed-by: J

hw/arm/virt-acpi-build: Modify the DSDT ACPI table to enable ACPI PCI hotplug

Modify the DSDT ACPI table to enable ACPI PCI hotplug.

Signed-off-by: Eric Auger <eric.auger@redhat.com>
Reviewed-by: Jonathan Cameron <jonathan.cameron@huawei.com>
Reviewed-by: Igor Mammedov <imammedo@redhat.com>
Message-Id: <20250714080639.2525563-24-eric.auger@redhat.com>
Reviewed-by: Michael S. Tsirkin <mst@redhat.com>
Signed-off-by: Michael S. Tsirkin <mst@redhat.com>

show more ...

hw/arm/virt: Basic CXL enablement on pci_expander_bridge instances pxb-cxl

Code based on i386/pc enablement.
The memory layout places space for 16 host bridge register regions after
the GIC_REDIST2

hw/arm/virt: Basic CXL enablement on pci_expander_bridge instances pxb-cxl

Code based on i386/pc enablement.
The memory layout places space for 16 host bridge register regions after
the GIC_REDIST2 in the extended memmap. This is a hole in the current
map so adding them here has no impact on placement of other memory regions
(tested with enough CPUs for GIC_REDIST2 to be in use.)
The high memory map is GiB aligned so the hole is there whatever the
size of memory or device_memory below this point.

The CFMWs are placed above the extended memmap. Note the existing
variable highest_gpa is the highest GPA that has been allocated at
a particular point in setting up the memory map. Whilst this caused
some confusion in review there are existing comments explaining this
so nothing is added.

The cxl_devices_state.host_mr provides a small space in which to place
the individual host bridge register regions for whatever host bridges are
allocated via -device pxb-cxl on the command line. The existing dynamic
sysbus infrastructure is not reused because pxb-cxl is a PCI device not
a sysbus one but these registers are directly in the main memory map,
not the PCI address space.

Only create the CEDT table if cxl=on set for the machine. Default to off.

Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Tested-by: Itaru Kitayama <itaru.kitayama@fujitsu.com>
Tested-by: Li Zhijian <lizhijian@fujitsu.com>
Message-id: 20250703104110.992379-4-Jonathan.Cameron@huawei.com
Reviewed-by: Peter Maydell <peter.maydell@linaro.org>
Signed-off-by: Peter Maydell <peter.maydell@linaro.org>

show more ...

MAX78000: Add AES to SOC

This commit adds AES to max78000_soc

Signed-off-by: Jackson Donaldson <jcksn@duck.com>
Reviewed-by: Peter Maydell <peter.maydell@linaro.org>
Message-id: 20250704223239.2487

MAX78000: Add AES to SOC

This commit adds AES to max78000_soc

Signed-off-by: Jackson Donaldson <jcksn@duck.com>
Reviewed-by: Peter Maydell <peter.maydell@linaro.org>
Message-id: 20250704223239.248781-12-jcksn@duck.com
Signed-off-by: Peter Maydell <peter.maydell@linaro.org>

show more ...

MAX78000: Add TRNG to SOC

This commit adds TRNG to max78000_soc

Signed-off-by: Jackson Donaldson
Message-id: 20250704223239.248781-10-jcksn@duck.com
Reviewed-by: Peter Maydell <peter.maydell@linaro

MAX78000: Add TRNG to SOC

This commit adds TRNG to max78000_soc

Signed-off-by: Jackson Donaldson
Message-id: 20250704223239.248781-10-jcksn@duck.com
Reviewed-by: Peter Maydell <peter.maydell@linaro.org>
Signed-off-by: Peter Maydell <peter.maydell@linaro.org>

show more ...

MAX78000: Add GCR to SOC

This commit adds the Global Control Register to
max78000_soc

Signed-off-by: Jackson Donaldson <jcksn@duck.com>
Reviewed-by: Peter Maydell <peter.maydell@linaro.org>
Message

MAX78000: Add GCR to SOC

This commit adds the Global Control Register to
max78000_soc

Signed-off-by: Jackson Donaldson <jcksn@duck.com>
Reviewed-by: Peter Maydell <peter.maydell@linaro.org>
Message-id: 20250704223239.248781-8-jcksn@duck.com
Signed-off-by: Peter Maydell <peter.maydell@linaro.org>

show more ...

MAX78000: Add UART to SOC

This commit adds UART to max78000_soc

Signed-off-by: Jackson Donaldson <jcksn@duck.com>
Reviewed-by: Peter Maydell <petermaydell@linaro.org>
Message-id: 20250704223239.248

MAX78000: Add UART to SOC

This commit adds UART to max78000_soc

Signed-off-by: Jackson Donaldson <jcksn@duck.com>
Reviewed-by: Peter Maydell <petermaydell@linaro.org>
Message-id: 20250704223239.248781-6-jcksn@duck.com
Signed-off-by: Peter Maydell <peter.maydell@linaro.org>

show more ...

MAX78000: Add ICC to SOC

This commit adds the instruction cache controller
to max78000_soc

Signed-off-by: Jackson Donaldson <jcksn@duck.com>
Reviewed-by: Peter Maydell <petermaydell@linaro.org>
Mes

MAX78000: Add ICC to SOC

This commit adds the instruction cache controller
to max78000_soc

Signed-off-by: Jackson Donaldson <jcksn@duck.com>
Reviewed-by: Peter Maydell <petermaydell@linaro.org>
Message-id: 20250704223239.248781-4-jcksn@duck.com
Signed-off-by: Peter Maydell <peter.maydell@linaro.org>

show more ...

MAX78000: Add MAX78000FTHR Machine

This patch adds support for the MAX78000FTHR machine.

The MAX78000FTHR contains a MAX78000 and a RISC-V core. This patch
implements only the MAX78000, which is Co

MAX78000: Add MAX78000FTHR Machine

This patch adds support for the MAX78000FTHR machine.

The MAX78000FTHR contains a MAX78000 and a RISC-V core. This patch
implements only the MAX78000, which is Cortex-M4 based.
Details can be found at:
https://www.analog.com/media/en/technical-documentation/user-guides/max78000-user-guide.pdf

Signed-off-by: Jackson Donaldson <jcksn@duck.com>
Reviewed-by: Peter Maydell <peter.maydell@linaro.org>
Message-id: 20250704223239.248781-2-jcksn@duck.com
Signed-off-by: Peter Maydell <peter.maydell@linaro.org>

show more ...