]> git.ipfire.org Git - thirdparty/qemu.git/log
thirdparty/qemu.git
4 weeks agohw/arm/xlnx-versal-virt: split into base/concrete classes
Luc Michel [Fri, 26 Sep 2025 07:08:00 +0000 (09:08 +0200)] 
hw/arm/xlnx-versal-virt: split into base/concrete classes

Split the xlnx-versal-virt machine type into a base abstract type and a
concrete type. There is no functional change. This is in preparation for
the versal2 machine.

Signed-off-by: Luc Michel <luc.michel@amd.com>
Reviewed-by: Francisco Iglesias <francisco.iglesias@amd.com>
Reviewed-by: Edgar E. Iglesias <edgar.iglesias@amd.com>
Tested-by: Philippe Mathieu-Daudé <philmd@linaro.org>
Reviewed-by: Philippe Mathieu-Daudé <philmd@linaro.org>
Message-id: 20250926070806.292065-43-luc.michel@amd.com
Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
4 weeks agohw/arm/xlnx-versal-virt: rename the machine to amd-versal-virt
Luc Michel [Fri, 26 Sep 2025 07:07:59 +0000 (09:07 +0200)] 
hw/arm/xlnx-versal-virt: rename the machine to amd-versal-virt

To align with current branding and ensure coherency with the upcoming
versal2 machine, rename the xlnx-versal-virt machine to amd-versal-virt.
Keep an alias of the old name to the new one for command-line backward
compatibility.

Signed-off-by: Luc Michel <luc.michel@amd.com>
Reviewed-by: Francisco Iglesias <francisco.iglesias@amd.com>
Reviewed-by: Philippe Mathieu-Daudé <philmd@linaro.org>
Reviewed-by: Edgar E. Iglesias <edgar.iglesias@amd.com>
Tested-by: Philippe Mathieu-Daudé <philmd@linaro.org>
Message-id: 20250926070806.292065-42-luc.michel@amd.com
Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
4 weeks agohw/arm/xlnx-versal: add versal2 SoC
Luc Michel [Fri, 26 Sep 2025 07:07:58 +0000 (09:07 +0200)] 
hw/arm/xlnx-versal: add versal2 SoC

Add the Versal Gen 2 (versal2) version of the Versal SoC family.
This version embeds up to 8 Cortex-A78AE cores (split into 4 clusters)
and 10 Cortex-R52 cores (split into 5 clusters). The similarities
between versal and versal2 in term of architecture allow to reuse the
VersalMap structure to almost fully describe the implemented parts of
versal2.

The versal2 eFuse device differs quite a lot from the versal one and is
left as future work.

Signed-off-by: Luc Michel <luc.michel@amd.com>
Reviewed-by: Francisco Iglesias <francisco.iglesias@amd.com>
Reviewed-by: Philippe Mathieu-Daudé <philmd@linaro.org>
Reviewed-by: Edgar E. Iglesias <edgar.iglesias@amd.com>
Tested-by: Philippe Mathieu-Daudé <philmd@linaro.org>
Message-id: 20250926070806.292065-41-luc.michel@amd.com
Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
4 weeks agotarget/arm/tcg/cpu64: add the cortex-a78ae CPU
Luc Michel [Fri, 26 Sep 2025 07:07:57 +0000 (09:07 +0200)] 
target/arm/tcg/cpu64: add the cortex-a78ae CPU

Add support for the ARM Cortex-A78AE CPU.

Signed-off-by: Luc Michel <luc.michel@amd.com>
Reviewed-by: Edgar E. Iglesias <edgar.iglesias@amd.com>
Reviewed-by: Peter Maydell <peter.maydell@linaro.org>
Tested-by: Philippe Mathieu-Daudé <philmd@linaro.org>
Message-id: 20250926070806.292065-40-luc.michel@amd.com
Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
4 weeks agohw/arm/xlnx-versal: add the target field in IRQ descriptor
Luc Michel [Fri, 26 Sep 2025 07:07:56 +0000 (09:07 +0200)] 
hw/arm/xlnx-versal: add the target field in IRQ descriptor

Add the target field in the IRQ descriptor. This allows to target an IRQ
to another IRQ controller than the GIC(s). Other supported targets are
the PMC PPU1 CPU interrupt controller and the EAM (Error management)
device. Those two devices are currently not implemented so IRQs
targeting those will be left unconnected. This is in preparation for
versal2.

Signed-off-by: Luc Michel <luc.michel@amd.com>
Reviewed-by: Francisco Iglesias <francisco.iglesias@amd.com>
Reviewed-by: Edgar E. Iglesias <edgar.iglesias@amd.com>
Tested-by: Philippe Mathieu-Daudé <philmd@linaro.org>
Message-id: 20250926070806.292065-39-luc.michel@amd.com
Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
4 weeks agohw/arm/xlnx-versal: add a per_cluster_gic switch to VersalCpuClusterMap
Luc Michel [Fri, 26 Sep 2025 07:07:55 +0000 (09:07 +0200)] 
hw/arm/xlnx-versal: add a per_cluster_gic switch to VersalCpuClusterMap

Add the per_cluster_gic switch to the VersalCpuClusterMap structure.
When set, this indicates that a GIC instance should by created
per-cluster instead of globally for the whole RPU or APU. This is in
preparation for versal2.

Signed-off-by: Luc Michel <luc.michel@amd.com>
Reviewed-by: Francisco Iglesias <francisco.iglesias@amd.com>
Reviewed-by: Philippe Mathieu-Daudé <philmd@linaro.org>
Reviewed-by: Edgar E. Iglesias <edgar.iglesias@amd.com>
Tested-by: Philippe Mathieu-Daudé <philmd@linaro.org>
Message-id: 20250926070806.292065-38-luc.michel@amd.com
Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
4 weeks agohw/misc/xlnx-versal-crl: add the versal2 version
Luc Michel [Fri, 26 Sep 2025 07:07:54 +0000 (09:07 +0200)] 
hw/misc/xlnx-versal-crl: add the versal2 version

Add the versal2 version of the CRL device. For the implemented part, it
is similar to the versal version but drives reset line of more devices.

Signed-off-by: Luc Michel <luc.michel@amd.com>
Reviewed-by: Francisco Iglesias <francisco.iglesias@amd.com>
Reviewed-by: Philippe Mathieu-Daudé <philmd@linaro.org>
Reviewed-by: Edgar E. Iglesias <edgar.iglesias@amd.com>
Tested-by: Philippe Mathieu-Daudé <philmd@linaro.org>
Message-id: 20250926070806.292065-37-luc.michel@amd.com
Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
4 weeks agohw/arm/xlnx-versal: tidy up
Luc Michel [Fri, 26 Sep 2025 07:07:53 +0000 (09:07 +0200)] 
hw/arm/xlnx-versal: tidy up

Remove now unused macros in xlnx-versal.[ch]. Those macros have been
replaced by the VersalMap structure that serves as a central description
for the SoC. The ones still in use in the versal_unimp function are
inlined.

Signed-off-by: Luc Michel <luc.michel@amd.com>
Reviewed-by: Francisco Iglesias <francisco.iglesias@amd.com>
Reviewed-by: Edgar E. Iglesias <edgar.iglesias@amd.com>
Tested-by: Philippe Mathieu-Daudé <philmd@linaro.org>
Message-id: 20250926070806.292065-36-luc.michel@amd.com
Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
4 weeks agohw/arm/xlnx-versal: use hw/arm/bsa.h for timer IRQ indices
Luc Michel [Fri, 26 Sep 2025 07:07:52 +0000 (09:07 +0200)] 
hw/arm/xlnx-versal: use hw/arm/bsa.h for timer IRQ indices

Use the bsa.h header for ARM timer and maintainance IRQ indices instead
of redefining our owns.

Signed-off-by: Luc Michel <luc.michel@amd.com>
Reviewed-by: Francisco Iglesias <francisco.iglesias@amd.com>
Reviewed-by: Philippe Mathieu-Daudé <philmd@linaro.org>
Reviewed-by: Edgar E. Iglesias <edgar.iglesias@amd.com>
Tested-by: Philippe Mathieu-Daudé <philmd@linaro.org>
Message-id: 20250926070806.292065-35-luc.michel@amd.com
Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
4 weeks agohw/arm/xlnx-versal: reconnect the CRL to the other devices
Luc Michel [Fri, 26 Sep 2025 07:07:51 +0000 (09:07 +0200)] 
hw/arm/xlnx-versal: reconnect the CRL to the other devices

The CRL connects to various devices through link properties to be able
to reset them. The connections were dropped during the SoC refactoring.
Reintroduce them now.

Rely on the QOM tree to retrieve the devices to connect. The component
parts of the device names are chosen to match the properties on the CRL.

Signed-off-by: Luc Michel <luc.michel@amd.com>
Reviewed-by: Francisco Iglesias <francisco.iglesias@amd.com>
Reviewed-by: Edgar E. Iglesias <edgar.iglesias@amd.com>
Tested-by: Philippe Mathieu-Daudé <philmd@linaro.org>
Message-id: 20250926070806.292065-34-luc.michel@amd.com
Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
4 weeks agohw/misc/xlnx-versal-crl: refactor device reset logic
Luc Michel [Fri, 26 Sep 2025 07:07:50 +0000 (09:07 +0200)] 
hw/misc/xlnx-versal-crl: refactor device reset logic

Refactor the device reset logic to have a common register write callback
for all the devices. This uses a decode function to map the register
address to the actual peripheral to reset. This refactoring changes the
CPU property name from cpu_r5[*] to rpu[*] to ease with the connections
in the Versal SoC. It also fixes a bug where the gem device pointer
was mapped to the usb link property.

Signed-off-by: Luc Michel <luc.michel@amd.com>
Reviewed-by: Francisco Iglesias <francisco.iglesias@amd.com>
Reviewed-by: Edgar E. Iglesias <edgar.iglesias@amd.com>
Tested-by: Philippe Mathieu-Daudé <philmd@linaro.org>
Message-id: 20250926070806.292065-33-luc.michel@amd.com
Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
4 weeks agohw/misc/xlnx-versal-crl: split into base/concrete classes
Luc Michel [Fri, 26 Sep 2025 07:07:49 +0000 (09:07 +0200)] 
hw/misc/xlnx-versal-crl: split into base/concrete classes

Split the TYPE_XLNX_VERSAL_CRL type into base and concrete classes. This
is in preparation for the versal2 version of the CRL.

Signed-off-by: Luc Michel <luc.michel@amd.com>
Reviewed-by: Francisco Iglesias <francisco.iglesias@amd.com>
Reviewed-by: Edgar E. Iglesias <edgar.iglesias@amd.com>
Tested-by: Philippe Mathieu-Daudé <philmd@linaro.org>
Message-id: 20250926070806.292065-32-luc.michel@amd.com
Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
4 weeks agohw/misc/xlnx-versal-crl: remove unnecessary include directives
Luc Michel [Fri, 26 Sep 2025 07:07:48 +0000 (09:07 +0200)] 
hw/misc/xlnx-versal-crl: remove unnecessary include directives

Drop unused include directives from xlnx-versal-crl.c

Signed-off-by: Luc Michel <luc.michel@amd.com>
Reviewed-by: Francisco Iglesias <francisco.iglesias@amd.com>
Reviewed-by: Edgar E. Iglesias <edgar.iglesias@amd.com>
Tested-by: Philippe Mathieu-Daudé <philmd@linaro.org>
Message-id: 20250926070806.292065-31-luc.michel@amd.com
Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
4 weeks agohw/arm/xlnx-versal: add the versal_get_num_cpu accessor
Luc Michel [Fri, 26 Sep 2025 07:07:47 +0000 (09:07 +0200)] 
hw/arm/xlnx-versal: add the versal_get_num_cpu accessor

Add the versal_get_num_cpu accessor to the Versal SoC to retrieve the
number of CPUs in the SoC. Use it in the xlnx-versal-virt machine.

Signed-off-by: Luc Michel <luc.michel@amd.com>
Reviewed-by: Francisco Iglesias <francisco.iglesias@amd.com>
Reviewed-by: Edgar E. Iglesias <edgar.iglesias@amd.com>
Tested-by: Philippe Mathieu-Daudé <philmd@linaro.org>
Message-id: 20250926070806.292065-30-luc.michel@amd.com
Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
4 weeks agohw/arm/xlnx-versal: ddr: refactor creation
Luc Michel [Fri, 26 Sep 2025 07:07:46 +0000 (09:07 +0200)] 
hw/arm/xlnx-versal: ddr: refactor creation

Refactor the DDR aperture regions creation using the VersalMap
structure. Device creation and FDT node creation are split into two
functions because the later must happen during ARM virtual bootloader
modify_dtb callback.

Signed-off-by: Luc Michel <luc.michel@amd.com>
Reviewed-by: Francisco Iglesias <francisco.iglesias@amd.com>
Reviewed-by: Edgar E. Iglesias <edgar.iglesias@amd.com>
Tested-by: Philippe Mathieu-Daudé <philmd@linaro.org>
Message-id: 20250926070806.292065-29-luc.michel@amd.com
Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
4 weeks agohw/arm/xlnx-versal: ocm: refactor creation
Luc Michel [Fri, 26 Sep 2025 07:07:45 +0000 (09:07 +0200)] 
hw/arm/xlnx-versal: ocm: refactor creation

Refactor the OCM creation using the VersalMap structure.

Signed-off-by: Luc Michel <luc.michel@amd.com>
Reviewed-by: Francisco Iglesias <francisco.iglesias@amd.com>
Reviewed-by: Edgar E. Iglesias <edgar.iglesias@amd.com>
Tested-by: Philippe Mathieu-Daudé <philmd@linaro.org>
Message-id: 20250926070806.292065-28-luc.michel@amd.com
Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
4 weeks agohw/arm/xlnx-versal: rpu: refactor creation
Luc Michel [Fri, 26 Sep 2025 07:07:44 +0000 (09:07 +0200)] 
hw/arm/xlnx-versal: rpu: refactor creation

Refactor the RPU cluster creation using the VersalMap structure. This
effectively instantiate the RPU GICv2 which was not instantiated before.

Signed-off-by: Luc Michel <luc.michel@amd.com>
Reviewed-by: Francisco Iglesias <francisco.iglesias@amd.com>
Reviewed-by: Edgar E. Iglesias <edgar.iglesias@amd.com>
Tested-by: Philippe Mathieu-Daudé <philmd@linaro.org>
Message-id: 20250926070806.292065-27-luc.michel@amd.com
Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
4 weeks agohw/arm/xlnx-versal: add support for GICv2
Luc Michel [Fri, 26 Sep 2025 07:07:43 +0000 (09:07 +0200)] 
hw/arm/xlnx-versal: add support for GICv2

Add support for GICv2 instantiation in the Versal SoC. This is in
preparation for the RPU refactoring.

Signed-off-by: Luc Michel <luc.michel@amd.com>
Reviewed-by: Francisco Iglesias <francisco.iglesias@amd.com>
Reviewed-by: Edgar E. Iglesias <edgar.iglesias@amd.com>
Tested-by: Philippe Mathieu-Daudé <philmd@linaro.org>
Message-id: 20250926070806.292065-26-luc.michel@amd.com
Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
4 weeks agohw/arm/xlnx-versal: add support for multiple GICs
Luc Michel [Fri, 26 Sep 2025 07:07:42 +0000 (09:07 +0200)] 
hw/arm/xlnx-versal: add support for multiple GICs

The Versal SoC contains two GICs: one GICv3 in the APU and one GICv2 in
the RPU (currently not instantiated). To prepare for the GICv2
instantiation, add support for multiple GICs when connecting interrupts.

When a GIC is created, the first-cpu-index property is set on it, and a
pointer to the GIC is stored in the intc array. When connecting an IRQ,
a TYPE_SPLIT_IRQ device is created with its num-lines property set to
the number of GICs in the SoC. The split device is used to fan out the
IRQ to all the GICs.

Signed-off-by: Luc Michel <luc.michel@amd.com>
Reviewed-by: Francisco Iglesias <francisco.iglesias@amd.com>
Reviewed-by: Edgar E. Iglesias <edgar.iglesias@amd.com>
Tested-by: Philippe Mathieu-Daudé <philmd@linaro.org>
Message-id: 20250926070806.292065-25-luc.michel@amd.com
Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
4 weeks agohw/intc/arm_gicv3: Introduce a 'first-cpu-index' property
Francisco Iglesias [Fri, 26 Sep 2025 07:07:41 +0000 (09:07 +0200)] 
hw/intc/arm_gicv3: Introduce a 'first-cpu-index' property

Introduce a 'first-cpu-index' property for specifying the first QEMU CPU
connected to the GICv3. This makes it possible to have multiple instances
of the GICv3 connected to different CPU clusters.

For KVM, mark this property has unsupported. It probably does not make
much sense as it is intented to be used to model non-SMP systems.

Signed-off-by: Luc Michel <luc.michel@amd.com>
Signed-off-by: Francisco Iglesias <francisco.iglesias@amd.com>
Reviewed-by: Sai Pavan Boddu <sai.pavan.boddu@amd.com>
Reviewed-by: Peter Maydell <peter.maydell@linaro.org>
Reviewed-by: Edgar E. Iglesias <edgar.iglesias@amd.com>
Tested-by: Philippe Mathieu-Daudé <philmd@linaro.org>
Message-id: 20250926070806.292065-24-luc.michel@amd.com
Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
4 weeks agohw/arm/xlnx-versal: instantiate the GIC ITS in the APU
Luc Michel [Fri, 26 Sep 2025 07:07:40 +0000 (09:07 +0200)] 
hw/arm/xlnx-versal: instantiate the GIC ITS in the APU

Add the instance of the GIC ITS in the APU.

Signed-off-by: Luc Michel <luc.michel@amd.com>
Reviewed-by: Francisco Iglesias <francisco.iglesias@amd.com>
Reviewed-by: Edgar E. Iglesias <edgar.iglesias@amd.com>
Tested-by: Philippe Mathieu-Daudé <philmd@linaro.org>
Message-id: 20250926070806.292065-23-luc.michel@amd.com
Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
4 weeks agohw/arm/xlnx-versal: add the mp_affinity property to the CPU mapping
Luc Michel [Fri, 26 Sep 2025 07:07:39 +0000 (09:07 +0200)] 
hw/arm/xlnx-versal: add the mp_affinity property to the CPU mapping

Add a way to configure the MP affinity value of the CPUs given their
core and cluster IDs. For the Versal APU CPUs, the MP affinity value is
given by the core ID in Aff0.

Signed-off-by: Luc Michel <luc.michel@amd.com>
Reviewed-by: Francisco Iglesias <francisco.iglesias@amd.com>
Reviewed-by: Edgar E. Iglesias <edgar.iglesias@amd.com>
Tested-by: Philippe Mathieu-Daudé <philmd@linaro.org>
Message-id: 20250926070806.292065-22-luc.michel@amd.com
Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
4 weeks agohw/arm/xlnx-versal: refactor CPU cluster creation
Luc Michel [Fri, 26 Sep 2025 07:07:38 +0000 (09:07 +0200)] 
hw/arm/xlnx-versal: refactor CPU cluster creation

Refactor the CPU cluster creation using the VersalMap structure. There
is no functional change. The clusters properties are now described in
the VersalMap structure. For now only the APU is converted. The RPU will
be taken care of by next commits.

Signed-off-by: Luc Michel <luc.michel@amd.com>
Reviewed-by: Francisco Iglesias <francisco.iglesias@amd.com>
Reviewed-by: Philippe Mathieu-Daudé <philmd@linaro.org>
Reviewed-by: Edgar E. Iglesias <edgar.iglesias@amd.com>
Tested-by: Philippe Mathieu-Daudé <philmd@linaro.org>
Message-id: 20250926070806.292065-21-luc.michel@amd.com
Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
4 weeks agohw/arm/xlnx-versal-virt: virtio: refactor creation
Luc Michel [Fri, 26 Sep 2025 07:07:37 +0000 (09:07 +0200)] 
hw/arm/xlnx-versal-virt: virtio: refactor creation

Refactor the creation of virtio devices. Use the accessors provided by
the Versal SoC to retrieve the reserved MMIO and IRQ space. Those are
defined in the VersalMap structure.

Signed-off-by: Luc Michel <luc.michel@amd.com>
Reviewed-by: Francisco Iglesias <francisco.iglesias@amd.com>
Reviewed-by: Edgar E. Iglesias <edgar.iglesias@amd.com>
Tested-by: Philippe Mathieu-Daudé <philmd@linaro.org>
Message-id: 20250926070806.292065-20-luc.michel@amd.com
Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
4 weeks agohw/arm/xlnx-versal: crl: refactor creation
Luc Michel [Fri, 26 Sep 2025 07:07:36 +0000 (09:07 +0200)] 
hw/arm/xlnx-versal: crl: refactor creation

Refactor the CRL device creation using the VersalMap structure. The
connections to the RPU CPUs are temporarily removed and will be
reintroduced with next refactoring commits.

Signed-off-by: Luc Michel <luc.michel@amd.com>
Reviewed-by: Francisco Iglesias <francisco.iglesias@amd.com>
Reviewed-by: Edgar E. Iglesias <edgar.iglesias@amd.com>
Tested-by: Philippe Mathieu-Daudé <philmd@linaro.org>
Message-id: 20250926070806.292065-19-luc.michel@amd.com
Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
4 weeks agohw/arm/xlnx-versal: cfu: refactor creation
Luc Michel [Fri, 26 Sep 2025 07:07:35 +0000 (09:07 +0200)] 
hw/arm/xlnx-versal: cfu: refactor creation

Refactor the CFU device creation using the VersalMap structure. All
users of the APB IRQ OR gate have now been converted. The OR gate device
can be dropped.

Signed-off-by: Luc Michel <luc.michel@amd.com>
Reviewed-by: Francisco Iglesias <francisco.iglesias@amd.com>
Reviewed-by: Edgar E. Iglesias <edgar.iglesias@amd.com>
Tested-by: Philippe Mathieu-Daudé <philmd@linaro.org>
Message-id: 20250926070806.292065-18-luc.michel@amd.com
Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
4 weeks agohw/arm/xlnx-versal: rtc: refactor creation
Luc Michel [Fri, 26 Sep 2025 07:07:34 +0000 (09:07 +0200)] 
hw/arm/xlnx-versal: rtc: refactor creation

Refactor the RTC device creation using the VersalMap structure.

The sysbus IRQ output 0 (APB IRQ) is connected instead of the output 1
(addr error IRQ). This does not change the current behaviour since the
RTC model does not implement those IRQs anyway.

Signed-off-by: Luc Michel <luc.michel@amd.com>
Reviewed-by: Francisco Iglesias <francisco.iglesias@amd.com>
Reviewed-by: Edgar E. Iglesias <edgar.iglesias@amd.com>
Tested-by: Philippe Mathieu-Daudé <philmd@linaro.org>
Message-id: 20250926070806.292065-17-luc.michel@amd.com
Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
4 weeks agohw/arm/xlnx-versal: trng: refactor creation
Luc Michel [Fri, 26 Sep 2025 07:07:33 +0000 (09:07 +0200)] 
hw/arm/xlnx-versal: trng: refactor creation

Refactor the TRNG device creation using the VersalMap structure.

Signed-off-by: Luc Michel <luc.michel@amd.com>
Reviewed-by: Francisco Iglesias <francisco.iglesias@amd.com>
Reviewed-by: Edgar E. Iglesias <edgar.iglesias@amd.com>
Tested-by: Philippe Mathieu-Daudé <philmd@linaro.org>
Message-id: 20250926070806.292065-16-luc.michel@amd.com
Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
4 weeks agohw/arm/xlnx-versal: bbram: refactor creation
Luc Michel [Fri, 26 Sep 2025 07:07:32 +0000 (09:07 +0200)] 
hw/arm/xlnx-versal: bbram: refactor creation

Refactor the BBRAM device creation using the VersalMap structure.

Note that the corresponding FDT node is removed. It does not correspond
to any real node in standard Versal DTBs. No matching drivers exist for
it.

Signed-off-by: Luc Michel <luc.michel@amd.com>
Reviewed-by: Francisco Iglesias <francisco.iglesias@amd.com>
Reviewed-by: Edgar E. Iglesias <edgar.iglesias@amd.com>
Tested-by: Philippe Mathieu-Daudé <philmd@linaro.org>
Message-id: 20250926070806.292065-15-luc.michel@amd.com
Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
4 weeks agohw/arm/xlnx-versal: PMC IOU SCLR: refactor creation
Luc Michel [Fri, 26 Sep 2025 07:07:31 +0000 (09:07 +0200)] 
hw/arm/xlnx-versal: PMC IOU SCLR: refactor creation

Refactor the PMC IOU SLCR device creation using the VersalMap structure.
This is the first user of a shared IRQ using an OR gate. The OSPI
controller is reconnected to the SLCR.

Signed-off-by: Luc Michel <luc.michel@amd.com>
Reviewed-by: Francisco Iglesias <francisco.iglesias@amd.com>
Reviewed-by: Edgar E. Iglesias <edgar.iglesias@amd.com>
Tested-by: Philippe Mathieu-Daudé <philmd@linaro.org>
Message-id: 20250926070806.292065-14-luc.michel@amd.com
Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
4 weeks agohw/arm/xlnx-versal: VersalMap: add support for OR'ed IRQs
Luc Michel [Fri, 26 Sep 2025 07:07:30 +0000 (09:07 +0200)] 
hw/arm/xlnx-versal: VersalMap: add support for OR'ed IRQs

Improve the IRQ index in the VersalMap structure to turn it into a
descriptor:
   - the lower 16 bits still represent the IRQ index
   - bit 18 is used to indicate a shared IRQ connected to a OR gate
   - bits 19 to 22 indicate the index on the OR gate.

This allows to share an IRQ among multiple devices. An OR gate is
created to connect the devices to the actual IRQ pin.

Signed-off-by: Luc Michel <luc.michel@amd.com>
Reviewed-by: Francisco Iglesias <francisco.iglesias@amd.com>
Reviewed-by: Philippe Mathieu-Daudé <philmd@linaro.org>
Reviewed-by: Edgar E. Iglesias <edgar.iglesias@amd.com>
Tested-by: Philippe Mathieu-Daudé <philmd@linaro.org>
Message-id: 20250926070806.292065-13-luc.michel@amd.com
Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
4 weeks agohw/arm/xlnx-versal: ospi: refactor creation
Luc Michel [Fri, 26 Sep 2025 07:07:29 +0000 (09:07 +0200)] 
hw/arm/xlnx-versal: ospi: refactor creation

Refactor the OSPI controller creation using the VersalMap structure.

Note that the connection to the PMC IOU SLCR is removed for now and will
be re-added by next commits.

Signed-off-by: Luc Michel <luc.michel@amd.com>
Reviewed-by: Francisco Iglesias <francisco.iglesias@amd.com>
Reviewed-by: Edgar E. Iglesias <edgar.iglesias@amd.com>
Tested-by: Philippe Mathieu-Daudé <philmd@linaro.org>
Message-id: 20250926070806.292065-12-luc.michel@amd.com
Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
4 weeks agohw/arm/xlnx-versal: efuse: refactor creation
Luc Michel [Fri, 26 Sep 2025 07:07:28 +0000 (09:07 +0200)] 
hw/arm/xlnx-versal: efuse: refactor creation

Refactore the eFuse devices creation using the VersalMap structure.

Note that the corresponding FDT nodes are removed. They do not
correspond to any real node in standard Versal DTBs. No matching drivers
exist for them.

Signed-off-by: Luc Michel <luc.michel@amd.com>
Reviewed-by: Francisco Iglesias <francisco.iglesias@amd.com>
Reviewed-by: Edgar E. Iglesias <edgar.iglesias@amd.com>
Tested-by: Philippe Mathieu-Daudé <philmd@linaro.org>
Message-id: 20250926070806.292065-11-luc.michel@amd.com
Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
4 weeks agohw/arm/xlnx-versal: usb: refactor creation
Luc Michel [Fri, 26 Sep 2025 07:07:27 +0000 (09:07 +0200)] 
hw/arm/xlnx-versal: usb: refactor creation

Refactor the USB controller creation using the VersalMap structure.

Note that the connection to the CRL is removed for now and will be
re-added by next commits.

Signed-off-by: Luc Michel <luc.michel@amd.com>
Reviewed-by: Francisco Iglesias <francisco.iglesias@amd.com>
Reviewed-by: Edgar E. Iglesias <edgar.iglesias@amd.com>
Tested-by: Philippe Mathieu-Daudé <philmd@linaro.org>
Message-id: 20250926070806.292065-10-luc.michel@amd.com
Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
4 weeks agohw/arm/xlnx-versal: xram: refactor creation
Luc Michel [Fri, 26 Sep 2025 07:07:26 +0000 (09:07 +0200)] 
hw/arm/xlnx-versal: xram: refactor creation

Refactor the XRAM devices creation using the VersalMap structure.

Signed-off-by: Luc Michel <luc.michel@amd.com>
Reviewed-by: Francisco Iglesias <francisco.iglesias@amd.com>
Reviewed-by: Edgar E. Iglesias <edgar.iglesias@amd.com>
Tested-by: Philippe Mathieu-Daudé <philmd@linaro.org>
Message-id: 20250926070806.292065-9-luc.michel@amd.com
Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
4 weeks agohw/arm/xlnx-versal: adma: refactor creation
Luc Michel [Fri, 26 Sep 2025 07:07:25 +0000 (09:07 +0200)] 
hw/arm/xlnx-versal: adma: refactor creation

Refactor the ADMA creation using the VersalMap structure.

Note that the connection to the CRL is removed for now and will be
re-added by next commits.

Signed-off-by: Luc Michel <luc.michel@amd.com>
Reviewed-by: Francisco Iglesias <francisco.iglesias@amd.com>
Reviewed-by: Edgar E. Iglesias <edgar.iglesias@amd.com>
Tested-by: Philippe Mathieu-Daudé <philmd@linaro.org>
Message-id: 20250926070806.292065-8-luc.michel@amd.com
Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
4 weeks agohw/arm/xlnx-versal: gem: refactor creation
Luc Michel [Fri, 26 Sep 2025 07:07:24 +0000 (09:07 +0200)] 
hw/arm/xlnx-versal: gem: refactor creation

Refactor the GEM ethernet controllers creation using the VersalMap
structure.

Note that the connection to the CRL is removed for now and will be
re-added by next commits.

The FDT nodes are created in reverse order compared to the devices
creation to keep backward compatibility with the previous generated
FDTs.

Signed-off-by: Luc Michel <luc.michel@amd.com>
Reviewed-by: Francisco Iglesias <francisco.iglesias@amd.com>
Reviewed-by: Edgar E. Iglesias <edgar.iglesias@amd.com>
Tested-by: Philippe Mathieu-Daudé <philmd@linaro.org>
Message-id: 20250926070806.292065-7-luc.michel@amd.com
Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
4 weeks agohw/arm/xlnx-versal: sdhci: refactor creation
Luc Michel [Fri, 26 Sep 2025 07:07:23 +0000 (09:07 +0200)] 
hw/arm/xlnx-versal: sdhci: refactor creation

Refactor the SDHCI controllers creation using the VersalMap structure.

Signed-off-by: Luc Michel <luc.michel@amd.com>
Reviewed-by: Francisco Iglesias <francisco.iglesias@amd.com>
Reviewed-by: Edgar E. Iglesias <edgar.iglesias@amd.com>
Tested-by: Philippe Mathieu-Daudé <philmd@linaro.org>
Message-id: 20250926070806.292065-6-luc.michel@amd.com
Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
4 weeks agohw/arm/xlnx-versal: canfd: refactor creation
Luc Michel [Fri, 26 Sep 2025 07:07:22 +0000 (09:07 +0200)] 
hw/arm/xlnx-versal: canfd: refactor creation

Refactor the CAN controllers creation using the VersalMap structure.

Note that the connection to the CRL is removed for now and will be
re-added by next commits.

The xlnx-versal-virt machine now dynamically creates the correct amount
of CAN bus link properties based on the number of CAN controller
advertised by the SoC.

Signed-off-by: Luc Michel <luc.michel@amd.com>
Reviewed-by: Francisco Iglesias <francisco.iglesias@amd.com>
Reviewed-by: Philippe Mathieu-Daudé <philmd@linaro.org>
Reviewed-by: Edgar E. Iglesias <edgar.iglesias@amd.com>
Tested-by: Philippe Mathieu-Daudé <philmd@linaro.org>
Message-id: 20250926070806.292065-5-luc.michel@amd.com
Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
4 weeks agohw/arm/xlnx-versal: uart: refactor creation
Luc Michel [Fri, 26 Sep 2025 07:07:21 +0000 (09:07 +0200)] 
hw/arm/xlnx-versal: uart: refactor creation

Refactor the UARTs creations. The VersalMap struct is now used to
describe the SoC and its peripherals. For now it contains the two UARTs
mapping information. The creation function now embeds the FDT creation
logic as well. The devices are now created dynamically using qdev_new
and (qdev|sysbus)_realize_and_unref.

This will allow to rely entirely on the VersalMap structure to create
the SoC and allow easy addition of new SoCs of the same family (like
versal2 coming with next commits).

Note that the connection to the CRL is removed for now and will be
re-added by next commits.

Signed-off-by: Luc Michel <luc.michel@amd.com>
Reviewed-by: Francisco Iglesias <francisco.iglesias@amd.com>
Reviewed-by: Edgar E. Iglesias <edgar.iglesias@amd.com>
Tested-by: Philippe Mathieu-Daudé <philmd@linaro.org>
Message-id: 20250926070806.292065-4-luc.michel@amd.com
Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
4 weeks agohw/arm/xlnx-versal: prepare for FDT creation
Luc Michel [Fri, 26 Sep 2025 07:07:20 +0000 (09:07 +0200)] 
hw/arm/xlnx-versal: prepare for FDT creation

The following commits will move FDT creation logic from the
xlnx-versal-virt machine to the xlnx-versal SoC itself. Prepare this by
passing the FDT handle to the SoC before it is realized.

For now the SoC only creates the two clock nodes. The ones from the
xlnx-versal virt machine are renamed with a `old-' prefix and will be
removed once they are not referenced anymore.

Signed-off-by: Luc Michel <luc.michel@amd.com>
Reviewed-by: Francisco Iglesias <francisco.iglesias@amd.com>
Reviewed-by: Edgar E. Iglesias <edgar.iglesias@amd.com>
Tested-by: Philippe Mathieu-Daudé <philmd@linaro.org>
Message-id: 20250926070806.292065-3-luc.michel@amd.com
Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
4 weeks agohw/arm/xlnx-versal: split the xlnx-versal type
Luc Michel [Fri, 26 Sep 2025 07:07:19 +0000 (09:07 +0200)] 
hw/arm/xlnx-versal: split the xlnx-versal type

Split the xlnx-versal device into two classes, a base, abstract class
and the existing concrete one. Introduce a VersalVersion type that will
be used across several device models when versal2 implementation is
added.

This is in preparation for versal2 implementation.

Signed-off-by: Luc Michel <luc.michel@amd.com>
Reviewed-by: Francisco Iglesias <francisco.iglesias@amd.com>
Reviewed-by: Philippe Mathieu-Daudé <philmd@linaro.org>
Reviewed-by: Edgar E. Iglesias <edgar.iglesias@amd.com>
Tested-by: Philippe Mathieu-Daudé <philmd@linaro.org>
Message-id: 20250926070806.292065-2-luc.michel@amd.com
Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
4 weeks agotarget/arm: Don't set HCR.RW for AArch32 only CPUs
Peter Maydell [Thu, 25 Sep 2025 11:57:23 +0000 (12:57 +0100)] 
target/arm: Don't set HCR.RW for AArch32 only CPUs

In commit 39ec3fc0301 we fixed a bug where we were not implementing
HCR_EL2.RW as RAO/WI for CPUs where EL1 doesn't support AArch32.
However, we got the condition wrong, so we now set this bit even on
CPUs which have no AArch64 support at all.  This is wrong because the
AArch32 HCR register defines this bit as RES0.

Correct the condition we use for forcing HCR_RW to be set.

Cc: qemu-stable@nongnu.org
Resolves: https://gitlab.com/qemu-project/qemu/-/issues/3128
Fixes: 39ec3fc0301 ("target/arm: HCR_EL2.RW should be RAO/WI if EL1 doesn't support AArch32")
Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
Reviewed-by: Philippe Mathieu-Daudé <philmd@linaro.org>
Reviewed-by: Richard Henderson <richard.henderson@linaro.org>
Message-id: 20250925115723.1293233-1-peter.maydell@linaro.org

4 weeks agohw/intc/loongarch_dintc: Set class_size for LoongArchDINTCClass
Richard Henderson [Mon, 6 Oct 2025 20:54:50 +0000 (13:54 -0700)] 
hw/intc/loongarch_dintc: Set class_size for LoongArchDINTCClass

Fixes: 4d4baab24179 ("loongarch: add a direct interrupt controller device")
Signed-off-by: Richard Henderson <richard.henderson@linaro.org>
4 weeks agoMerge tag 'for_upstream' of https://git.kernel.org/pub/scm/virt/kvm/mst/qemu into...
Richard Henderson [Mon, 6 Oct 2025 15:14:03 +0000 (08:14 -0700)] 
Merge tag 'for_upstream' of https://git.kernel.org/pub/scm/virt/kvm/mst/qemu into staging

virtio,pci,pc: features, fixes

users can now control VM bit in smbios.
vhost-user-device is now user-createable.
intel_iommu now supports PRI
virtio-net now supports GSO over UDP tunnel
ghes now supports error injection
amd iommu now supports dma remapping for vfio
better error messages for virtio

small fixes all over the place.

Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
# -----BEGIN PGP SIGNATURE-----
#
# iQFDBAABCgAtFiEEXQn9CHHI+FuUyooNKB8NuNKNVGkFAmji0s0PHG1zdEByZWRo
# YXQuY29tAAoJECgfDbjSjVRpuH4H/09h70IqAWZGHIWKGmmGGtdKOj3g54KuI0Ss
# mGECEsHvvBexOy670Qy8jdgXfaW4UuNui8BiOnJnGsBX8Y0dy+/yZori3KhkXkaY
# D57Ap9agkpHem7Vw0zgNsAF2bzDdlzTiQ6ns5oDnSq8yt82onCb5WGkWTGkPs/jL
# Gf8Jv+Ddcpt5SU4/hHPYC8pUhl7z4xPOOyl0Qp1GG21Pxf5v4sGFcWuGGB7UEPSQ
# MjZeoM0rSnLDtNg18sGwD5RPLQs13TbtgsVwijI79c3w3rcSpPNhGR5OWkdRCIYF
# 8A0Nhq0Yfo0ogTht7yt1QNPf/ktJkuoBuGVirvpDaix2tCBECes=
# =Zvq/
# -----END PGP SIGNATURE-----
# gpg: Signature made Sun 05 Oct 2025 01:19:25 PM PDT
# gpg:                using RSA key 5D09FD0871C8F85B94CA8A0D281F0DB8D28D5469
# gpg:                issuer "mst@redhat.com"
# gpg: Good signature from "Michael S. Tsirkin <mst@kernel.org>" [unknown]
# gpg:                 aka "Michael S. Tsirkin <mst@redhat.com>" [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: 0270 606B 6F3C DF3D 0B17  0970 C350 3912 AFBE 8E67
#      Subkey fingerprint: 5D09 FD08 71C8 F85B 94CA  8A0D 281F 0DB8 D28D 5469

* tag 'for_upstream' of https://git.kernel.org/pub/scm/virt/kvm/mst/qemu: (75 commits)
  virtio: improve virtqueue mapping error messages
  pci: Fix wrong parameter passing to pci_device_get_iommu_bus_devfn()
  intel_iommu: Simplify caching mode check with VFIO device
  intel_iommu: Enable Enhanced Set Root Table Pointer Support (ESRTPS)
  vdpa-dev: add get_vhost() callback for vhost-vdpa device
  amd_iommu: HATDis/HATS=11 support
  intel-iommu: Move dma_translation to x86-iommu
  amd_iommu: Refactor amdvi_page_walk() to use common code for page walk
  amd_iommu: Do not assume passthrough translation when DTE[TV]=0
  amd_iommu: Toggle address translation mode on devtab entry invalidation
  amd_iommu: Add dma-remap property to AMD vIOMMU device
  amd_iommu: Set all address spaces to use passthrough mode on reset
  amd_iommu: Toggle memory regions based on address translation mode
  amd_iommu: Invalidate address translations on INVALIDATE_IOMMU_ALL
  amd_iommu: Add replay callback
  amd_iommu: Unmap all address spaces under the AMD IOMMU on reset
  amd_iommu: Use iova_tree records to determine large page size on UNMAP
  amd_iommu: Sync shadow page tables on page invalidation
  amd_iommu: Add basic structure to support IOMMU notifier updates
  amd_iommu: Add a page walker to sync shadow page tables on invalidation
  ...

Signed-off-by: Richard Henderson <richard.henderson@linaro.org>
4 weeks agoMerge tag 'block-pull-request' of https://gitlab.com/stefanha/qemu into staging
Richard Henderson [Mon, 6 Oct 2025 15:13:46 +0000 (08:13 -0700)] 
Merge tag 'block-pull-request' of https://gitlab.com/stefanha/qemu into staging

Pull request

A checkpatch.pl improvement for the QEMU BH APIs.

# -----BEGIN PGP SIGNATURE-----
#
# iQEzBAABCgAdFiEEhpWov9P5fNqsNXdanKSrs4Grc8gFAmjj2TEACgkQnKSrs4Gr
# c8iAxwf+Pt4Pc6/8CuwSzz+uREnKZr9qHtFDwcvlJrlGwJLH7AAGOv5l5Ay8A/yC
# qmfLGlKjbpLLuh+A4q7pdFffbOP1goS8GeyoLRPRV9w3WhTp0GQovRp8BAxzNvCz
# qpWwjsCSNVq990IuoJCBl6/GWAOg9fgwzhZwufmiV6+xiYI+bg1au8ehU+eB824s
# BiOa9trkzfAXUmNLliL7MOZpoi5UlHV5Yt0Jp0TZ9h8NmAURGQ2XXA7FadXbE9Ft
# Wl2ToPqIMnlFeCF9HOhBaK1JaoagmgOphrcPjqGHYdW4cU4KME/s1zI1NOhyq/7P
# v8xYLsKn00IX10RWSWl4Vw8NTSzAcA==
# =8B2l
# -----END PGP SIGNATURE-----
# gpg: Signature made Mon 06 Oct 2025 07:58:57 AM PDT
# gpg:                using RSA key 8695A8BFD3F97CDAAC35775A9CA4ABB381AB73C8
# gpg: Good signature from "Stefan Hajnoczi <stefanha@redhat.com>" [unknown]
# gpg:                 aka "Stefan Hajnoczi <stefanha@gmail.com>" [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: 8695 A8BF D3F9 7CDA AC35  775A 9CA4 ABB3 81AB 73C8

* tag 'block-pull-request' of https://gitlab.com/stefanha/qemu:
  scripts/checkpatch: Avoid recommending legacy qemu_bh_new_guarded()

Signed-off-by: Richard Henderson <richard.henderson@linaro.org>
4 weeks agoMerge tag 'samuel-thibault' of https://people.debian.org/~sthibault/qemu into staging
Richard Henderson [Mon, 6 Oct 2025 15:11:59 +0000 (08:11 -0700)] 
Merge tag 'samuel-thibault' of https://people.debian.org/~sthibault/qemu into staging

Add a feature for mapping a host unix socket to a guest tcp socket

# -----BEGIN PGP SIGNATURE-----
#
# iQIzBAABCgAdFiEE4vRkF7O8asAeqx2F3PytNJui1S8FAmjixEQACgkQ3PytNJui
# 1S/prg/+I154XOH+ST2IbUzlg/wLnVmH9X0HcIbatdY55tsW1RLm89RRQjPCsogF
# HcLT+AKu4T43c2QFMQU9aetYVXSJP17PZXYG1grwBC6S+nwOVpJSI5q/nmwQ7llE
# 0wG+yDoclLyaJ4cfBbYKLAa3aLb+mFWqineLJCOyhht5Lwg285PkDyCIo1TzerR0
# beR8xinxrfXgF9ELtQhvjHosfggw3+s/6EIXVI6uYdBLRwymYyebaI3JZr4aN9Kx
# 1rsj1PVMAyN1GJaV7ZJwHBRKNX7h9xtxx/TI7oFV8/kwx/PUOsoXWOSZufXDb5CU
# ltkZAQ788XkBGV5CaQfDiyZGfLd8wwcKI8rwes3uxrzUnzEyo1qJKeKPlrxiyC2h
# 0RtJZhC/973YDc0aQB9y4J0HP77DNwLlCCVtkS23/rk1EwSwHBwbxtENsDSuj9CY
# Nn9oFlhJpULGoPMpMvcOGC/PRpt/+58Vu4lDCFUlr84tNLPhUHhq/dh8/LhbL/SE
# 2UOw93aXrA6NQLnVczauX6VL+e0PACOzelAQZujRQuJf/Hi9cvJT6WsvBL75UQGF
# 5xC3D/Oraqeg8z+9NJkp9X5qOLAo6v4m4sXbiMDkMSD5IsxkHmmLEqE1WBjGu8jt
# 453ghqwyRQJLUv9G+AxRn3tSg1+0s/pKTtZ388EWz5xIM9pdn/A=
# =HIIY
# -----END PGP SIGNATURE-----
# gpg: Signature made Sun 05 Oct 2025 12:17:24 PM PDT
# gpg:                using RSA key E2F46417B3BC6AC01EAB1D85DCFCAD349BA2D52F
# gpg: Good signature from "Samuel Thibault <samuel.thibault@ens-lyon.org>" [unknown]
# gpg:                 aka "Samuel Thibault <sthibault@debian.org>" [unknown]
# gpg:                 aka "Samuel Thibault <samuel.thibault@gnu.org>" [unknown]
# gpg:                 aka "Samuel Thibault <samuel.thibault@inria.fr>" [unknown]
# gpg:                 aka "Samuel Thibault <samuel.thibault@labri.fr>" [unknown]
# gpg:                 aka "Samuel Thibault <samuel.thibault@aquilenet.fr>" [unknown]
# gpg:                 aka "Samuel Thibault <samuel.thibault@u-bordeaux.fr>" [unknown]
# gpg:                 aka "Samuel Thibault <sthibault@hypra.fr>" [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: 900C B024 B679 31D4 0F82  304B D017 8C76 7D06 9EE6
#      Subkey fingerprint: E2F4 6417 B3BC 6AC0 1EAB  1D85 DCFC AD34 9BA2 D52F

* tag 'samuel-thibault' of https://people.debian.org/~sthibault/qemu:
  Add a feature for mapping a host unix socket to a guest tcp socket

Signed-off-by: Richard Henderson <richard.henderson@linaro.org>
4 weeks agoMerge tag 'pull-trivial-patches' of https://gitlab.com/mjt0k/qemu into staging
Richard Henderson [Mon, 6 Oct 2025 15:11:02 +0000 (08:11 -0700)] 
Merge tag 'pull-trivial-patches' of https://gitlab.com/mjt0k/qemu into staging

trivial patches for 2025-10-05

# -----BEGIN PGP SIGNATURE-----
#
# iQIzBAABCgAdFiEEZKoqtTHVaQM2a/75gqpKJDselHgFAmjiFiUACgkQgqpKJDse
# lHitTBAAnv7RI9gCW7cc1y+BDPl+gqRuo8f+d1Mg/bUMf5BVjtPYUjzlwW1dShT+
# W4cOwBZbuKt/EqodQvkBpaZrv3mlfVSmSWAYy5egL5naRgHOqnzcbt3nVSpJBfrI
# VWMYJDT8owU80gRpeJ70UEQgBUxJ6ipnBgTuo6ILfDYAaOGIgvh6UMqdPQqHjULV
# CCv+TgIs6Uu4clZvPunHjaqnocvxnSWzpn6sy0xzk94QDNTW2ijBMAEhjKcUE9GA
# 2UhqVeiHvRVhAkGOTR2JNXtwwl864JHtJ4TqfilE8OUVF2+KcG3t5j8SI0JLgvRz
# sjHcFaOuVQXz2xVQv1dD6xVeq0YxkMIHMVe0ScN4WtVNTc8y5zdUSaphEcT7ELWe
# a4juN1qTqJ7B0h1BqCJoKY6fhWAcKhQccESKmXoxuiiXTOJb436F0IXPWzeByg+2
# Hm+dtgjCoOaR8KRgx7dS3zowMFCUDE0HqyHQVj974455bzlwdc3LIO2KniLtbZgV
# rt6JWbn5poBcRkSBXV2SI78dls10Dn+So/ecmJjxMz+61hBN+t6oqTdaaPaLnyUL
# yDwwn5Ji91hQO+hBL4+wRw+Ssbmz8YcdEyacbtgIE+erS0lHt9Df/21rSTSI3xRl
# 0sj+WTSQ1Ar7CwE8veVNqvgdZRc45kHvBwYXyxgLADmcGqok5wM=
# =gc8G
# -----END PGP SIGNATURE-----
# gpg: Signature made Sat 04 Oct 2025 11:54:29 PM PDT
# gpg:                using RSA key 64AA2AB531D56903366BFEF982AA4A243B1E9478
# gpg: Good signature from "Michael Tokarev <mjt@debian.org>" [unknown]
# gpg:                 aka "Michael Tokarev <mjt@corpit.ru>" [unknown]
# gpg:                 aka "Michael Tokarev <mjt@tls.msk.ru>" [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: 9D8B E14E 3F2A 9DD7 9199  28F1 61AD 3D98 ECDF 2C8E
#      Subkey fingerprint: 64AA 2AB5 31D5 6903 366B  FEF9 82AA 4A24 3B1E 9478

* tag 'pull-trivial-patches' of https://gitlab.com/mjt0k/qemu:
  system/runstate: remove duplicate in runstate transitions
  docs/specs/spdm.rst: Fix typo in x86_64 architecture name
  docs/devel: Correct uefi-vars-x64 device name
  wdt_i6300esb: fix incorrect mask for interrupt type
  hid: fix incorrect return value for hid
  vhost-user-test: remove trailing newlines in g_test_message() calls
  hw/net/can: Remove redundant status bit setting in can_sja1000
  ui/gtk: Fix callback function signature

Signed-off-by: Richard Henderson <richard.henderson@linaro.org>
4 weeks agoscripts/checkpatch: Avoid recommending legacy qemu_bh_new_guarded()
Philippe Mathieu-Daudé [Wed, 24 Sep 2025 16:39:11 +0000 (18:39 +0200)] 
scripts/checkpatch: Avoid recommending legacy qemu_bh_new_guarded()

qemu_bh_new_guarded() is considered legacy since commit 9c86c97f12c
("async: Add an optional reentrancy guard to the BH API"); recommend
the new API: aio_bh_new_guarded().

Signed-off-by: Philippe Mathieu-Daudé <philmd@linaro.org>
Message-ID: <20250924163911.51479-1-philmd@linaro.org>
Signed-off-by: Stefan Hajnoczi <stefanha@redhat.com>
4 weeks agovirtio: improve virtqueue mapping error messages
Alessandro Ratti [Wed, 24 Sep 2025 09:14:04 +0000 (11:14 +0200)] 
virtio: improve virtqueue mapping error messages

Improve error reporting when virtqueue ring mapping fails by including a
device identifier in the error message.

Introduce a helper qdev_get_printable_name() in qdev-core, which returns
either:

 - the device ID, if explicitly provided (e.g. -device ...,id=foo)
 - the QOM path from qdev_get_dev_path(dev) otherwise
 - "<unknown device>" as a fallback when no identifier is present

This makes it easier to identify which device triggered the error in
multi-device setups or when debugging complex guest configurations.

Resolves: https://gitlab.com/qemu-project/qemu/-/issues/230
Buglink: https://bugs.launchpad.net/qemu/+bug/1919021
Suggested-by: Markus Armbruster <armbru@redhat.com>
Signed-off-by: Alessandro Ratti <alessandro@0x65c.net>
Message-Id: <20250924093138.559872-2-alessandro@0x65c.net>
Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>
Reviewed-by: Michael S. Tsirkin <mst@redhat.com>
Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
4 weeks agopci: Fix wrong parameter passing to pci_device_get_iommu_bus_devfn()
Zhenzhong Duan [Mon, 29 Sep 2025 03:42:06 +0000 (23:42 -0400)] 
pci: Fix wrong parameter passing to pci_device_get_iommu_bus_devfn()

The 2nd parameter of pci_device_get_iommu_bus_devfn() about root PCIBus
backed by an IOMMU for the PCI device, the 3rd is about aliased PCIBus
of the PCI device.

Meanwhile the 3rd and 4th parameters are optional, pass NULL if they
are not needed.

Reviewed-by: Clément Mathieu--Drif <clement.mathieu--drif@eviden.com>
Reviewed-by: Michael S. Tsirkin <mst@redhat.com>
Message-ID: <20250929034206.439266-4-zhenzhong.duan@intel.com>
Fixes: a849ff5d6f ("pci: Add a pci-level initialization function for IOMMU notifiers")
Fixes: f0f37daf8e ("pci: Add a PCI-level API for PRI")
Fixes: e9b457500a ("pci: Add a pci-level API for ATS")
Fixes: 042cbc9aec ("pci: Add an API to get IOMMU's min page size and virtual address width")
Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
4 weeks agointel_iommu: Simplify caching mode check with VFIO device
Zhenzhong Duan [Mon, 29 Sep 2025 03:42:05 +0000 (23:42 -0400)] 
intel_iommu: Simplify caching mode check with VFIO device

In early days, we had different tricks to ensure caching-mode=on with VFIO
device:

28cf553afe ("intel_iommu: Sanity check vfio-pci config on machine init done")
c6cbc29d36 ("pc/q35: Disallow vfio-pci hotplug without VT-d caching mode")

There is also a patch with the same purpose but for VDPA device:

b8d78277c0 ("intel-iommu: fail MAP notifier without caching mode")

Because without caching mode, MAP notifier won't work correctly since guest
won't send IOTLB update event when it establishes new mappings in the I/O page
tables.

Now with host IOMMU device interface between VFIO and vIOMMU, we can simplify
first two commits above with a small check in set_iommu_device(). This also
works for future IOMMUFD backed VDPA implementation which may also need caching
mode on. But for legacy VDPA we still need commit b8d78277c0 as it doesn't
use the host IOMMU device interface.

For coldplug VFIO device:

  qemu-system-x86_64: -device vfio-pci,host=0000:3b:00.0,id=hostdev3,bus=root0,iommufd=iommufd0: vfio 0000:3b:00.0: Failed to set vIOMMU: Device assignment is not allowed without enabling caching-mode=on for Intel IOMMU.

For hotplug VFIO device:

  if "iommu=off" is configured in guest,
    Error: vfio 0000:3b:00.0: Failed to set vIOMMU: Device assignment is not allowed without enabling caching-mode=on for Intel IOMMU.
  else
    Error: vfio 0000:3b:00.0: memory listener initialization failed: Region vtd-00.0-dmar: device 01.00.0 requires caching mode: Operation not supported

The specialty for hotplug is due to the check in commit b8d78277c0 happen before
the check in set_iommu_device.

Signed-off-by: Zhenzhong Duan <zhenzhong.duan@intel.com>
Reviewed-by: Michael S. Tsirkin <mst@redhat.com>
Message-ID: <20250929034206.439266-3-zhenzhong.duan@intel.com>
Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
4 weeks agointel_iommu: Enable Enhanced Set Root Table Pointer Support (ESRTPS)
Zhenzhong Duan [Mon, 29 Sep 2025 03:42:04 +0000 (23:42 -0400)] 
intel_iommu: Enable Enhanced Set Root Table Pointer Support (ESRTPS)

According to VTD spec rev 4.1 section 6.6:
"For implementations reporting the Enhanced Set Root Table Pointer Support
(ESRTPS) field as Clear, on a 'Set Root Table Pointer' operation, software
must perform a global invalidate of the context cache, PASID-cache (if
applicable), and IOTLB, in that order. This is required to ensure hardware
references only the remapping structures referenced by the new root table
pointer and not stale cached entries.

For implementations reporting the Enhanced Set Root Table Pointer Support
(ESRTPS) field as Set, as part of 'Set Root Table Pointer' operation,
hardware performs global invalidation on all DMA remapping translation
caches and hence software is not required to perform additional
invalidations"

We already implemented ESRTPS capability in vtd_handle_gcmd_srtp() by
calling vtd_reset_caches(), just set ESRTPS in DMAR_CAP_REG to avoid
unnecessary global invalidation requests of context, PASID-cache and
IOTLB from guest.

This change doesn't impact migration as the content of DMAR_CAP_REG is
migrated too.

Signed-off-by: Zhenzhong Duan <zhenzhong.duan@intel.com>
Reviewed-by: Clément Mathieu--Drif <clement.mathieu--drif@eviden.com>
Reviewed-by: Michael S. Tsirkin <mst@redhat.com>
Message-ID: <20250929034206.439266-2-zhenzhong.duan@intel.com>
Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
4 weeks agovdpa-dev: add get_vhost() callback for vhost-vdpa device
Li Zhaoxin [Fri, 26 Sep 2025 11:08:17 +0000 (19:08 +0800)] 
vdpa-dev: add get_vhost() callback for vhost-vdpa device

Commit c255488d67 "virtio: add vhost support for virtio devices"
added the get_vhost() function, but it did not include vhost-vdpa devices.

So when I use the vdpa device and query the status of the vdpa device
with the x-query-virtio-status qmp command, since vdpa does not implement
vhost_get, it will cause qemu to crash.

Therefore, in order to obtain the status of the virtio device under vhost-vdpa,
we need to add a vhost_get implement for the vdpa device.

Co-developed-by: Miao Kezhan <miaokezhan@baidu.com>
Signed-off-by: Miao Kezhan <miaokezhan@baidu.com>
Signed-off-by: Li Zhaoxin <lizhaoxin04@baidu.com>
Reviewed-by: Michael S. Tsirkin <mst@redhat.com>
Message-ID: <2778f817cb6740a15ecb37927804a67288b062d1.1758860411.git.lizhaoxin04@baidu.com>
Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
4 weeks agoamd_iommu: HATDis/HATS=11 support
Joao Martins [Fri, 19 Sep 2025 21:35:15 +0000 (21:35 +0000)] 
amd_iommu: HATDis/HATS=11 support

Add a way to disable DMA translation support in AMD IOMMU by
allowing to set IVHD HATDis to 1, and exposing HATS (Host Address
Translation Size) as Reserved value.

Signed-off-by: Joao Martins <joao.m.martins@oracle.com>
Signed-off-by: Alejandro Jimenez <alejandro.j.jimenez@oracle.com>
Reviewed-by: Michael S. Tsirkin <mst@redhat.com>
Message-ID: <20250919213515.917111-23-alejandro.j.jimenez@oracle.com>
Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
4 weeks agointel-iommu: Move dma_translation to x86-iommu
Joao Martins [Fri, 19 Sep 2025 21:35:14 +0000 (21:35 +0000)] 
intel-iommu: Move dma_translation to x86-iommu

To be later reused by AMD, now that it shares similar property.

Signed-off-by: Joao Martins <joao.m.martins@oracle.com>
Signed-off-by: Alejandro Jimenez <alejandro.j.jimenez@oracle.com>
Reviewed-by: Michael S. Tsirkin <mst@redhat.com>
Message-ID: <20250919213515.917111-22-alejandro.j.jimenez@oracle.com>
Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
4 weeks agoamd_iommu: Refactor amdvi_page_walk() to use common code for page walk
Alejandro Jimenez [Fri, 19 Sep 2025 21:35:13 +0000 (21:35 +0000)] 
amd_iommu: Refactor amdvi_page_walk() to use common code for page walk

Simplify amdvi_page_walk() by making it call the fetch_pte() helper that is
already in use by the shadow page synchronization code. Ensures all code
uses the same page table walking algorithm.

Signed-off-by: Alejandro Jimenez <alejandro.j.jimenez@oracle.com>
Reviewed-by: Michael S. Tsirkin <mst@redhat.com>
Message-ID: <20250919213515.917111-21-alejandro.j.jimenez@oracle.com>
Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
4 weeks agoamd_iommu: Do not assume passthrough translation when DTE[TV]=0
Alejandro Jimenez [Fri, 19 Sep 2025 21:35:12 +0000 (21:35 +0000)] 
amd_iommu: Do not assume passthrough translation when DTE[TV]=0

The AMD I/O Virtualization Technology (IOMMU) Specification (see Table
8: V, TV, and GV Fields in Device Table Entry), specifies that a DTE
with V=1, TV=0 does not contain a valid address translation information.
If a request requires a table walk, the walk is terminated when this
condition is encountered.

Do not assume that addresses for a device with DTE[TV]=0 are passed
through (i.e. not remapped) and instead terminate the page table walk
early.

Fixes: d29a09ca6842 ("hw/i386: Introduce AMD IOMMU")
Signed-off-by: Alejandro Jimenez <alejandro.j.jimenez@oracle.com>
Reviewed-by: Michael S. Tsirkin <mst@redhat.com>
Message-ID: <20250919213515.917111-20-alejandro.j.jimenez@oracle.com>
Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
4 weeks agoamd_iommu: Toggle address translation mode on devtab entry invalidation
Alejandro Jimenez [Fri, 19 Sep 2025 21:35:11 +0000 (21:35 +0000)] 
amd_iommu: Toggle address translation mode on devtab entry invalidation

A guest must issue an INVALIDATE_DEVTAB_ENTRY command after changing a
Device Table entry (DTE) e.g. after attaching a device and setting up its
DTE. When intercepting this event, determine if the DTE has been configured
for paging or not, and toggle the appropriate memory regions to allow DMA
address translation for the address space if needed. Requires dma-remap=on.

Signed-off-by: Alejandro Jimenez <alejandro.j.jimenez@oracle.com>
Reviewed-by: Michael S. Tsirkin <mst@redhat.com>
Message-ID: <20250919213515.917111-19-alejandro.j.jimenez@oracle.com>
Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
4 weeks agoamd_iommu: Add dma-remap property to AMD vIOMMU device
Alejandro Jimenez [Fri, 19 Sep 2025 21:35:10 +0000 (21:35 +0000)] 
amd_iommu: Add dma-remap property to AMD vIOMMU device

In order to enable device assignment with IOMMU protection and guest DMA
address translation, IOMMU MAP notifier support is necessary to allow users
like VFIO to synchronize the shadow page tables i.e. to receive
notifications when the guest updates its I/O page tables and replay the
mappings onto host I/O page tables.

Provide a new dma-remap property to govern the ability to register for MAP
notifications, effectively providing global control over the DMA address
translation functionality that was implemented in previous changes.

Note that DMA remapping support also requires the vIOMMU is configured with
the NpCache capability, so a guest driver issues IOMMU invalidations for
both map() and unmap() operations. This capability is already set by default
and written to the configuration in amdvi_pci_realize() as part of
AMDVI_CAPAB_FEATURES.

Signed-off-by: Alejandro Jimenez <alejandro.j.jimenez@oracle.com>
Reviewed-by: Michael S. Tsirkin <mst@redhat.com>
Message-ID: <20250919213515.917111-18-alejandro.j.jimenez@oracle.com>
Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
4 weeks agoamd_iommu: Set all address spaces to use passthrough mode on reset
Alejandro Jimenez [Fri, 19 Sep 2025 21:35:09 +0000 (21:35 +0000)] 
amd_iommu: Set all address spaces to use passthrough mode on reset

On reset, restore the default address translation mode (passthrough) for all
the address spaces managed by the vIOMMU.

Signed-off-by: Alejandro Jimenez <alejandro.j.jimenez@oracle.com>
Reviewed-by: Michael S. Tsirkin <mst@redhat.com>
Message-ID: <20250919213515.917111-17-alejandro.j.jimenez@oracle.com>
Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
4 weeks agoamd_iommu: Toggle memory regions based on address translation mode
Alejandro Jimenez [Fri, 19 Sep 2025 21:35:08 +0000 (21:35 +0000)] 
amd_iommu: Toggle memory regions based on address translation mode

Enable the appropriate memory region for an address space depending on the
address translation mode selected for it. This is currently based on a
generic x86 IOMMU property, and only done during the address space
initialization. Extract the code into a helper and toggle the regions based
on whether the specific address space is using address translation (via the
newly introduced addr_translation field). Later, region activation will also
be controlled by availability of DMA remapping capability (via dma-remap
property to be introduced in follow up changes).

Signed-off-by: Alejandro Jimenez <alejandro.j.jimenez@oracle.com>
Reviewed-by: Michael S. Tsirkin <mst@redhat.com>
Message-ID: <20250919213515.917111-16-alejandro.j.jimenez@oracle.com>
Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
4 weeks agoamd_iommu: Invalidate address translations on INVALIDATE_IOMMU_ALL
Alejandro Jimenez [Fri, 19 Sep 2025 21:35:07 +0000 (21:35 +0000)] 
amd_iommu: Invalidate address translations on INVALIDATE_IOMMU_ALL

When the kernel IOMMU driver issues an INVALIDATE_IOMMU_ALL, the address
translation and interrupt remapping information must be cleared for all
Device IDs and all domains. Introduce a helper to sync the shadow page table
for all the address spaces with registered notifiers, which replays both MAP
and UNMAP events.

Signed-off-by: Alejandro Jimenez <alejandro.j.jimenez@oracle.com>
Reviewed-by: Michael S. Tsirkin <mst@redhat.com>
Message-ID: <20250919213515.917111-15-alejandro.j.jimenez@oracle.com>
Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
4 weeks agoamd_iommu: Add replay callback
Alejandro Jimenez [Fri, 19 Sep 2025 21:35:06 +0000 (21:35 +0000)] 
amd_iommu: Add replay callback

A replay() method is necessary to efficiently synchronize the host page
tables after VFIO registers a notifier for IOMMU events. It is called to
ensure that existing mappings from an IOMMU memory region are "replayed" to
a specified notifier, initializing or updating the shadow page tables on the
host.

Signed-off-by: Alejandro Jimenez <alejandro.j.jimenez@oracle.com>
Reviewed-by: Michael S. Tsirkin <mst@redhat.com>
Message-ID: <20250919213515.917111-14-alejandro.j.jimenez@oracle.com>
Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
4 weeks agoamd_iommu: Unmap all address spaces under the AMD IOMMU on reset
Alejandro Jimenez [Fri, 19 Sep 2025 21:35:05 +0000 (21:35 +0000)] 
amd_iommu: Unmap all address spaces under the AMD IOMMU on reset

Support dropping all existing mappings on reset. When the guest kernel
reboots it will create new ones, but other components that run before
the kernel (e.g. OVMF) should not be able to use existing mappings from
the previous boot.

Signed-off-by: Alejandro Jimenez <alejandro.j.jimenez@oracle.com>
Reviewed-by: Michael S. Tsirkin <mst@redhat.com>
Message-ID: <20250919213515.917111-13-alejandro.j.jimenez@oracle.com>
Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
4 weeks agoamd_iommu: Use iova_tree records to determine large page size on UNMAP
Alejandro Jimenez [Fri, 19 Sep 2025 21:35:04 +0000 (21:35 +0000)] 
amd_iommu: Use iova_tree records to determine large page size on UNMAP

Keep a record of mapped IOVA ranges per address space, using the iova_tree
implementation. Besides enabling optimizations like avoiding unnecessary
notifications, a record of existing <IOVA, size> mappings makes it possible
to determine if a specific IOVA is mapped by the guest using a large page,
and adjust the size when notifying UNMAP events.

When unmapping a large page, the information in the guest PTE encoding the
page size is lost, since the guest clears the PTE before issuing the
invalidation command to the IOMMU. In such case, the size of the original
mapping can be retrieved from the iova_tree and used to issue the UNMAP
notification. Using the correct size is essential since the VFIO IOMMU
Type1v2 driver in the host kernel will reject unmap requests that do not
fully cover previous mappings.

Signed-off-by: Alejandro Jimenez <alejandro.j.jimenez@oracle.com>
Reviewed-by: Michael S. Tsirkin <mst@redhat.com>
Message-ID: <20250919213515.917111-12-alejandro.j.jimenez@oracle.com>
Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
4 weeks agoamd_iommu: Sync shadow page tables on page invalidation
Alejandro Jimenez [Fri, 19 Sep 2025 21:35:03 +0000 (21:35 +0000)] 
amd_iommu: Sync shadow page tables on page invalidation

When the guest issues an INVALIDATE_IOMMU_PAGES command, decode the address
and size of the invalidation and sync the guest page table state with the
host. This requires walking the guest page table and calling notifiers
registered for address spaces matching the domain ID encoded in the command.

Signed-off-by: Alejandro Jimenez <alejandro.j.jimenez@oracle.com>
Reviewed-by: Michael S. Tsirkin <mst@redhat.com>
Message-ID: <20250919213515.917111-11-alejandro.j.jimenez@oracle.com>
Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
4 weeks agoamd_iommu: Add basic structure to support IOMMU notifier updates
Alejandro Jimenez [Fri, 19 Sep 2025 21:35:02 +0000 (21:35 +0000)] 
amd_iommu: Add basic structure to support IOMMU notifier updates

Add the minimal data structures required to maintain a list of address
spaces (i.e. devices) with registered notifiers, and to update the type of
events that require notifications.
Note that the ability to register for MAP notifications is not available.
It will be unblocked by following changes that enable the synchronization of
guest I/O page tables with host IOMMU state, at which point an amd-iommu
device property will be introduced to control this capability.

Signed-off-by: Alejandro Jimenez <alejandro.j.jimenez@oracle.com>
Reviewed-by: Michael S. Tsirkin <mst@redhat.com>
Message-ID: <20250919213515.917111-10-alejandro.j.jimenez@oracle.com>
Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
4 weeks agoamd_iommu: Add a page walker to sync shadow page tables on invalidation
Alejandro Jimenez [Fri, 19 Sep 2025 21:35:01 +0000 (21:35 +0000)] 
amd_iommu: Add a page walker to sync shadow page tables on invalidation

For the specified address range, walk the page table identifying regions
as mapped or unmapped and invoke registered notifiers with the
corresponding event type.

Signed-off-by: Alejandro Jimenez <alejandro.j.jimenez@oracle.com>
Reviewed-by: Michael S. Tsirkin <mst@redhat.com>
Message-ID: <20250919213515.917111-9-alejandro.j.jimenez@oracle.com>
Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
4 weeks agoamd_iommu: Add helpers to walk AMD v1 Page Table format
Alejandro Jimenez [Fri, 19 Sep 2025 21:35:00 +0000 (21:35 +0000)] 
amd_iommu: Add helpers to walk AMD v1 Page Table format

The current amdvi_page_walk() is designed to be called by the replay()
method. Rather than drastically altering it, introduce helpers to fetch
guest PTEs that will be used by a page walker implementation.

Signed-off-by: Alejandro Jimenez <alejandro.j.jimenez@oracle.com>
Reviewed-by: Michael S. Tsirkin <mst@redhat.com>
Message-ID: <20250919213515.917111-8-alejandro.j.jimenez@oracle.com>
Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
4 weeks agoamd_iommu: Return an error when unable to read PTE from guest memory
Alejandro Jimenez [Fri, 19 Sep 2025 21:34:59 +0000 (21:34 +0000)] 
amd_iommu: Return an error when unable to read PTE from guest memory

Make amdvi_get_pte_entry() return an error value (-1) in cases where the
memory read fails, versus the current return of 0 to indicate failure.
The reason is that 0 is also a valid value to have stored in the PTE in
guest memory i.e. the guest does not have a mapping. Before this change,
amdvi_get_pte_entry() returned 0 for both an error and for empty PTEs, but
the page walker implementation that will be introduced in upcoming changes
needs a method to differentiate between the two scenarios.

Signed-off-by: Alejandro Jimenez <alejandro.j.jimenez@oracle.com>
Reviewed-by: Michael S. Tsirkin <mst@redhat.com>
Message-ID: <20250919213515.917111-7-alejandro.j.jimenez@oracle.com>
Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
4 weeks agoamd_iommu: Add helper function to extract the DTE
Alejandro Jimenez [Fri, 19 Sep 2025 21:34:58 +0000 (21:34 +0000)] 
amd_iommu: Add helper function to extract the DTE

Extracting the DTE from a given AMDVIAddressSpace pointer structure is a
common operation required for syncing the shadow page tables. Implement a
helper to do it and check for common error conditions.

Signed-off-by: Alejandro Jimenez <alejandro.j.jimenez@oracle.com>
Reviewed-by: Michael S. Tsirkin <mst@redhat.com>
Message-ID: <20250919213515.917111-6-alejandro.j.jimenez@oracle.com>
Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
4 weeks agoamd_iommu: Helper to decode size of page invalidation command
Alejandro Jimenez [Fri, 19 Sep 2025 21:34:57 +0000 (21:34 +0000)] 
amd_iommu: Helper to decode size of page invalidation command

The size of the region to invalidate depends on the S bit and address
encoded in the command. Add a helper to extract this information, which
will be used to sync shadow page tables in upcoming changes.

Signed-off-by: Alejandro Jimenez <alejandro.j.jimenez@oracle.com>
Reviewed-by: Michael S. Tsirkin <mst@redhat.com>
Message-ID: <20250919213515.917111-5-alejandro.j.jimenez@oracle.com>
Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
4 weeks agoamd_iommu: Reorder device and page table helpers
Alejandro Jimenez [Fri, 19 Sep 2025 21:34:56 +0000 (21:34 +0000)] 
amd_iommu: Reorder device and page table helpers

Move code related to Device Table and Page Table to an earlier location in
the file, where it does not require forward declarations to be used by the
various invalidation functions that will need to query the DTE and walk the
page table in upcoming changes.

This change consist of code movement only, no functional change intended.

Signed-off-by: Alejandro Jimenez <alejandro.j.jimenez@oracle.com>
Reviewed-by: Michael S. Tsirkin <mst@redhat.com>
Message-ID: <20250919213515.917111-4-alejandro.j.jimenez@oracle.com>
Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
4 weeks agoamd_iommu: Document '-device amd-iommu' common options
Alejandro Jimenez [Fri, 19 Sep 2025 21:34:55 +0000 (21:34 +0000)] 
amd_iommu: Document '-device amd-iommu' common options

Document the common parameters used when emulating AMD vIOMMU.
Besides the two amd-iommu specific options: 'xtsup' and 'dma-remap', the
the generic x86 IOMMU option 'intremap' is also included, since it is
typically specified in QEMU command line examples and mailing list threads.

Signed-off-by: Alejandro Jimenez <alejandro.j.jimenez@oracle.com>
Reviewed-by: Michael S. Tsirkin <mst@redhat.com>
Message-ID: <20250919213515.917111-3-alejandro.j.jimenez@oracle.com>
Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
4 weeks agomemory: Adjust event ranges to fit within notifier boundaries
Alejandro Jimenez [Fri, 19 Sep 2025 21:34:54 +0000 (21:34 +0000)] 
memory: Adjust event ranges to fit within notifier boundaries

Invalidating the entire address space (i.e. range of [0, ~0ULL]) is a
valid and required operation by vIOMMU implementations. However, such
invalidations currently trigger an assertion unless they originate from
device IOTLB invalidations.

Although in recent Linux guests this case is not exercised by the VTD
implementation due to various optimizations, the assertion will be hit
by upcoming AMD vIOMMU changes to support DMA address translation. More
specifically, when running a Linux guest with VFIO passthrough device,
and a kernel that does not contain commmit 3f2571fed2fa ("iommu/amd:
Remove redundant domain flush from attach_device()").

Remove the assertion altogether and adjust the range to ensure it does
not cross notifier boundaries.

Signed-off-by: Alejandro Jimenez <alejandro.j.jimenez@oracle.com>
Acked-by: Michael S. Tsirkin <mst@redhat.com>
Acked-by: David Hildenbrand <david@redhat.com>
Acked-by: Peter Xu <peterx@redhat.com>
Message-Id: <20201116165506.31315-6-eperezma@redhat.com>
Reviewed-by: Michael S. Tsirkin <mst@redhat.com>
Message-ID: <20250919213515.917111-2-alejandro.j.jimenez@oracle.com>
Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
4 weeks agoAdd a feature for mapping a host unix socket to a guest tcp socket
Viktor Kurilko [Fri, 8 Aug 2025 14:29:25 +0000 (21:29 +0700)] 
Add a feature for mapping a host unix socket to a guest tcp socket

This patch adds the ability to map a host unix socket to a guest tcp socket when
using the slirp backend. This feature was added in libslirp version 4.7.0.

A new syntax for unix socket: -hostfwd=unix:hostpath-[guestaddr]:guestport

Signed-off-by: Viktor Kurilko <murlockkinght@gmail.com>
Signed-off-by: Samuel Thibault <samuel.thibault@ens-lyon.org>
Message-ID: <20250808143904.363907-1-murlockkinght@gmail.com>

4 weeks agopcie_sriov: make pcie_sriov_pf_exit() safe on non-SR-IOV devices
Stefan Hajnoczi [Wed, 24 Sep 2025 15:51:53 +0000 (11:51 -0400)] 
pcie_sriov: make pcie_sriov_pf_exit() safe on non-SR-IOV devices

Commit 3f9cfaa92c96 ("virtio-pci: Implement SR-IOV PF") added an
unconditional call from virtio_pci_exit() to pcie_sriov_pf_exit().

pcie_sriov_pf_exit() reads from the SR-IOV Capability in Configuration
Space:

  uint8_t *cfg = dev->config + dev->exp.sriov_cap;
  ...
  unparent_vfs(dev, pci_get_word(cfg + PCI_SRIOV_TOTAL_VF));
                    ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

This results in undefined behavior when dev->exp.sriov_cap is 0 because
this is not an SR-IOV device. For example, unparent_vfs() segfaults when
total_vfs happens to be non-zero.

Fix this by returning early from pcie_sriov_pf_exit() when
dev->exp.sriov_cap is 0 because this is not an SR-IOV device.

Cc: Akihiko Odaki <odaki@rsg.ci.i.u-tokyo.ac.jp>
Cc: Michael S. Tsirkin <mst@redhat.com>
Reported-by: Qing Wang <qinwang@redhat.com>
Buglink: https://issues.redhat.com/browse/RHEL-116443
Signed-off-by: Stefan Hajnoczi <stefanha@redhat.com>
Reviewed-by: Akihiko Odaki <odaki@rsg.ci.i.u-tokyo.ac.jp>
Fixes: cab1398a60eb ("pcie_sriov: Reuse SR-IOV VF device instances")
Reviewed-by: Michael S. Tsirkin <mst@redhat.com>
Message-ID: <20250924155153.579495-1-stefanha@redhat.com>
Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
4 weeks agotests/virtio-scsi: add a virtio_error() IOThread test
Stefan Hajnoczi [Mon, 22 Sep 2025 22:01:49 +0000 (18:01 -0400)] 
tests/virtio-scsi: add a virtio_error() IOThread test

Now that virtio_error() calls should work in an IOThread, add a
virtio-scsi IOThread test cases that triggers virtio_error().

Signed-off-by: Stefan Hajnoczi <stefanha@redhat.com>
Reviewed-by: Michael S. Tsirkin <mst@redhat.com>
Message-ID: <20250922220149.498967-6-stefanha@redhat.com>
Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
4 weeks agotests/libqos: extract qvirtqueue_set_avail_idx()
Stefan Hajnoczi [Mon, 22 Sep 2025 22:01:48 +0000 (18:01 -0400)] 
tests/libqos: extract qvirtqueue_set_avail_idx()

Setting the vring's avail.idx can be useful for low-level VIRTIO tests,
especially for testing error scenarios with invalid vrings. Extract it
into a new function so that the next commit can add a test that uses
this new test API.

Signed-off-by: Stefan Hajnoczi <stefanha@redhat.com>
Acked-by: Fabiano Rosas <farosas@suse.de>
Reviewed-by: Philippe Mathieu-Daudé <philmd@linaro.org>
Reviewed-by: Michael S. Tsirkin <mst@redhat.com>
Message-ID: <20250922220149.498967-5-stefanha@redhat.com>
Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
4 weeks agovirtio: support irqfd in virtio_notify_config()
Stefan Hajnoczi [Mon, 22 Sep 2025 22:01:47 +0000 (18:01 -0400)] 
virtio: support irqfd in virtio_notify_config()

virtio_error() calls virtio_notify_config() to inject a VIRTIO
Configuration Change Notification. This doesn't work from IOThreads
because the BQL is not held and the interrupt code path requires the
BQL.

Follow the same approach as virtio_notify() and use ->config_notifier
(an irqfd) when called from the IOThread.

Signed-off-by: Stefan Hajnoczi <stefanha@redhat.com>
Reviewed-by: Michael S. Tsirkin <mst@redhat.com>
Message-ID: <20250922220149.498967-4-stefanha@redhat.com>
Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
4 weeks agovirtio: unify virtio_notify_irqfd() and virtio_notify()
Stefan Hajnoczi [Mon, 22 Sep 2025 22:01:46 +0000 (18:01 -0400)] 
virtio: unify virtio_notify_irqfd() and virtio_notify()

The difference between these two functions:
- virtio_notify() uses the interrupt code path (MSI or classic IRQs)
- virtio_notify_irqfd() uses guest notifiers (irqfds)

virtio_notify() can only be called with the BQL held because the
interrupt code path requires the BQL. Device models use
virtio_notify_irqfd() from IOThreads since the BQL is not held.

The two functions can be unified by pushing down the if
(qemu_in_iothread()) check from virtio-blk and virtio-scsi into core
virtio code. This is in preparation for the next commit that will add
irqfd support to virtio_notify_config() and where it's unattractive to
introduce another irqfd-only API for device model callers.

Signed-off-by: Stefan Hajnoczi <stefanha@redhat.com>
Reviewed-by: Philippe Mathieu-Daudé <philmd@linaro.org>
Reviewed-by: Michael S. Tsirkin <mst@redhat.com>
Message-ID: <20250922220149.498967-3-stefanha@redhat.com>
Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
4 weeks agovhost: use virtio_config_get_guest_notifier()
Stefan Hajnoczi [Mon, 22 Sep 2025 22:01:45 +0000 (18:01 -0400)] 
vhost: use virtio_config_get_guest_notifier()

There is a getter function so avoid accessing the ->config_notifier
field directly.

Signed-off-by: Stefan Hajnoczi <stefanha@redhat.com>
Reviewed-by: Philippe Mathieu-Daudé <philmd@linaro.org>
Reviewed-by: Michael S. Tsirkin <mst@redhat.com>
Message-ID: <20250922220149.498967-2-stefanha@redhat.com>
Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
4 weeks agox86: ich9: fix default value of 'No Reboot' bit in GCS
Igor Mammedov [Mon, 22 Sep 2025 13:26:00 +0000 (15:26 +0200)] 
x86: ich9: fix default value of 'No Reboot' bit in GCS

[2] initialized 'No Reboot' bit to 1 by default. And due to quirk it happened
to work with linux iTCO_wdt driver (which clears it on module load).

However spec [1] states:
"
R/W. This bit is set when the “No Reboot” strap (SPKR pin on
ICH9) is sampled high on PWROK.
"

So it should be set only when  '-global ICH9-LPC.noreboot=true' and cleared
when it's false (which should be default).

Fix it to behave according to spec and set 'No Reboot' bit only when
'-global ICH9-LPC.noreboot=true'.

1)
Intel I/O Controller Hub 9 (ICH9) Family Datasheet (rev: 004)
2)

Fixes: 920557971b6 (ich9: add TCO interface emulation)
Signed-off-by: Igor Mammedov <imammedo@redhat.com>
Tested-by: Daniel P. Berrangé <berrange@redhat.com>
Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>
Reviewed-by: Michael S. Tsirkin <mst@redhat.com>
Message-ID: <20250922132600.562193-1-imammedo@redhat.com>
Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
4 weeks agointel_iommu: Add PRI operations support
CLEMENT MATHIEU--DRIF [Mon, 1 Sep 2025 11:17:24 +0000 (11:17 +0000)] 
intel_iommu: Add PRI operations support

Implement the PRI callbacks in vtd_iommu_ops.

Signed-off-by: Clement Mathieu--Drif <clement.mathieu--drif@eviden.com>
Reviewed-by: Michael S. Tsirkin <mst@redhat.com>
Message-ID: <20250901111630.1018573-6-clement.mathieu--drif@eviden.com>
Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
4 weeks agointel_iommu: Declare registers for PRI
CLEMENT MATHIEU--DRIF [Mon, 1 Sep 2025 11:17:23 +0000 (11:17 +0000)] 
intel_iommu: Declare registers for PRI

Signed-off-by: Clement Mathieu--Drif <clement.mathieu--drif@eviden.com>
Reviewed-by: Michael S. Tsirkin <mst@redhat.com>
Message-ID: <20250901111630.1018573-5-clement.mathieu--drif@eviden.com>
Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
4 weeks agointel_iommu: Declare PRI constants and structures
CLEMENT MATHIEU--DRIF [Mon, 1 Sep 2025 11:17:21 +0000 (11:17 +0000)] 
intel_iommu: Declare PRI constants and structures

Signed-off-by: Clement Mathieu--Drif <clement.mathieu--drif@eviden.com>
Reviewed-by: Michael S. Tsirkin <mst@redhat.com>
Message-ID: <20250901111630.1018573-4-clement.mathieu--drif@eviden.com>
Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
4 weeks agointel_iommu: Bypass barrier wait descriptor
CLEMENT MATHIEU--DRIF [Mon, 1 Sep 2025 11:17:20 +0000 (11:17 +0000)] 
intel_iommu: Bypass barrier wait descriptor

wait_desc with SW=0,IF=0,FN=1 must not be considered as an
invalid descriptor as it is used to implement section 7.10 of
the VT-d spec.

Signed-off-by: Clement Mathieu--Drif <clement.mathieu--drif@eviden.com>
Reviewed-by: Michael S. Tsirkin <mst@redhat.com>
Message-ID: <20250901111630.1018573-3-clement.mathieu--drif@eviden.com>
Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
4 weeks agopcie: Add a way to get the outstanding page request allocation (pri) from the config...
CLEMENT MATHIEU--DRIF [Mon, 1 Sep 2025 11:17:19 +0000 (11:17 +0000)] 
pcie: Add a way to get the outstanding page request allocation (pri) from the config space.

Signed-off-by: Clement Mathieu--Drif <clement.mathieu--drif@eviden.com>
Reviewed-by: Michael S. Tsirkin <mst@redhat.com>
Message-ID: <20250901111630.1018573-2-clement.mathieu--drif@eviden.com>
Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
4 weeks agosmbios: cap DIMM size to 2Tb as workaround for broken Windows
Igor Mammedov [Mon, 1 Sep 2025 08:49:15 +0000 (10:49 +0200)] 
smbios: cap DIMM size to 2Tb as workaround for broken Windows

With current limit set to match max spec size (2PTb),
Windows fails to parse type 17 records when DIMM size reaches 4Tb+.
Failure happens in GetPhysicallyInstalledSystemMemory() function,
and fails "Check SMBIOS System Memory Tables" SVVP test.
Though not fatal, it might cause issues for userspace apps,
something like [1].

Lets cap default DIMM size to 2Tb for now, until MS fixes it.

1) https://issues.redhat.com/browse/RHEL-81999?focusedId=27731200&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-27731200

PS: It's obvious 32 int overflow math somewhere in Windows,
    MS admitted that it's Windows bug and in a process of fixing it.
    However it's unclear if W10 and earlier would get the fix.
    So however I dislike changing defaults, we heed to work around
    the issue (it looks like QEMU regression while not being it).
    Hopefully 2Tb/DIMM split will last longer until VM memory size
    will become large enough to cause to many type 17 records issue
    again.
PPS:
    Alternatively, instead of messing with defaults, we can create
    a dedicated knob to ask for desired DIMM size cap explicitly
    on CLI. That will let users to enable workaround when they
    hit this corner case. Downside is that knob has to be propagated
    up all mgmt stack, which might be not desirable.
PPPS:
    Yet alternatively, users can configure initial RAM to be less
    than 4Tb and all additional RAM add as DIMMs on QEMU CLI.
    (however it's the job to be done by mgmt which could know
    Windows version and total amount of RAM)

Signed-off-by: Igor Mammedov <imammedo@redhat.com>
Fixes: 62f182c97b ("smbios: make memory device size configurable per Machine")
Reviewed-by: Michael S. Tsirkin <mst@redhat.com>
Message-ID: <20250901084915.2607632-1-imammedo@redhat.com>
Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
4 weeks agohw/virtio: rename vhost-user-device and make user creatable
Alex Bennée [Mon, 1 Sep 2025 10:59:48 +0000 (11:59 +0100)] 
hw/virtio: rename vhost-user-device and make user creatable

We didn't make the device user creatable in the first place because we
were worried users might get confused. Rename the device to make its
nature as a test device even more explicit. While we are at it add a
Kconfig variable so it can be skipped for those that want to thin out
their build configuration even further.

Acked-by: Stefano Garzarella <sgarzare@redhat.com>
Reviewed-by: Manos Pitsidianakis <manos.pitsidianakis@linaro.org>
Reviewed-by: Stefan Hajnoczi <stefanha@redhat.com>
Signed-off-by: Alex Bennée <alex.bennee@linaro.org>
Message-ID: <20250820195632.1956795-1-alex.bennee@linaro.org>
Reviewed-by: Michael S. Tsirkin <mst@redhat.com>
Message-ID: <20250901105948.982583-1-alex.bennee@linaro.org>
Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
4 weeks agopcie_sriov: Fix broken MMIO accesses from SR-IOV VFs
Damien Bergamini [Mon, 1 Sep 2025 15:14:23 +0000 (15:14 +0000)] 
pcie_sriov: Fix broken MMIO accesses from SR-IOV VFs

Starting with commit cab1398a60eb, SR-IOV VFs are realized as soon as
pcie_sriov_pf_init() is called.  Because pcie_sriov_pf_init() must be
called before pcie_sriov_pf_init_vf_bar(), the VF BARs types won't be
known when the VF realize function calls pcie_sriov_vf_register_bar().

This breaks the memory regions of the VFs (for instance with igbvf):

$ lspci
...
    Region 0: Memory at 281a00000 (64-bit, prefetchable) [virtual] [size=16K]
    Region 3: Memory at 281a20000 (64-bit, prefetchable) [virtual] [size=16K]

$ info mtree
...
address-space: pci_bridge_pci_mem
  0000000000000000-ffffffffffffffff (prio 0, i/o): pci_bridge_pci
    0000000081a00000-0000000081a03fff (prio 1, i/o): igbvf-mmio
    0000000081a20000-0000000081a23fff (prio 1, i/o): igbvf-msix

and causes MMIO accesses to fail:

    Invalid write at addr 0x281A01520, size 4, region '(null)', reason: rejected
    Invalid read at addr 0x281A00C40, size 4, region '(null)', reason: rejected

To fix this, VF BARs are now registered with pci_register_bar() which
has a type parameter and pcie_sriov_vf_register_bar() is removed.

Fixes: cab1398a60eb ("pcie_sriov: Reuse SR-IOV VF device instances")
Signed-off-by: Damien Bergamini <damien.bergamini@eviden.com>
Signed-off-by: Clement Mathieu--Drif <clement.mathieu--drif@eviden.com>
Reviewed-by: Akihiko Odaki <odaki@rsg.ci.i.u-tokyo.ac.jp>
Reviewed-by: Michael S. Tsirkin <mst@redhat.com>
Message-ID: <20250901151314.1038020-1-clement.mathieu--drif@eviden.com>
Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
4 weeks agohw/i386/pc: Avoid overlap between CXL window and PCI 64bit BARs in QEMU
peng guo [Tue, 5 Aug 2025 14:23:00 +0000 (22:23 +0800)] 
hw/i386/pc: Avoid overlap between CXL window and PCI 64bit BARs in QEMU

When using a CXL Type 3 device together with a virtio 9p device in QEMU on a
physical server, the 9p device fails to initialize properly. The kernel reports
the following error:

    virtio: device uses modern interface but does not have VIRTIO_F_VERSION_1
    9pnet_virtio virtio0: probe with driver 9pnet_virtio failed with error -22

Further investigation revealed that the 64-bit BAR space assigned to the 9pnet
device was overlapped by the memory window allocated for the CXL devices. As a
result, the kernel could not correctly access the BAR region, causing the
virtio device to malfunction.

An excerpt from /proc/iomem shows:

    480010000-cffffffff : CXL Window 0
      480010000-4bfffffff : PCI Bus 0000:00
      4c0000000-4c01fffff : PCI Bus 0000:0c
        4c0000000-4c01fffff : PCI Bus 0000:0d
      4c0200000-cffffffff : PCI Bus 0000:00
        4c0200000-4c0203fff : 0000:00:03.0
          4c0200000-4c0203fff : virtio-pci-modern

To address this issue, this patch adds the reserved memory end calculation
for cxl devices to reserve sufficient address space and ensure that CXL memory
windows are allocated beyond all PCI 64-bit BARs. This prevents overlap with
64-bit BARs regions such as those used by virtio or other pcie devices,
resolving the conflict.

QEMU Build Configuration:

    ./configure --prefix=/home/work/qemu_master/build/ \
                --target-list=x86_64-softmmu \
                --enable-kvm \
                --enable-virtfs

QEMU Boot Command:

    sudo /home/work/qemu_master/qemu/build/qemu-system-x86_64 \
        -nographic -machine q35,cxl=on -enable-kvm -m 16G -smp 8 \
        -hda /home/work/gp_qemu/rootfs.img \
        -virtfs local,path=/home/work/gp_qemu/share,mount_tag=host0,security_model=passthrough,id=host0 \
        -kernel /home/work/linux_output/arch/x86/boot/bzImage \
        --append "console=ttyS0 crashkernel=256M root=/dev/sda rootfstype=ext4 rw loglevel=8" \
        -object memory-backend-ram,id=vmem0,share=on,size=4096M \
        -device pxb-cxl,bus_nr=12,bus=pcie.0,id=cxl.1 \
        -device cxl-rp,port=0,bus=cxl.1,id=root_port13,chassis=0,slot=2 \
        -device cxl-type3,bus=root_port13,volatile-memdev=vmem0,id=cxl-vmem0,sn=0x123456789 \
        -M cxl-fmw.0.targets.0=cxl.1,cxl-fmw.0.size=4G

Fixes: 03b39fcf64bc ("hw/cxl: Make the CXL fixed memory window setup a machine parameter")
Signed-off-by: peng guo <engguopeng@buaa.edu.cn>
Reviewed-by: Michael S. Tsirkin <mst@redhat.com>
Message-ID: <20250805142300.15226-1-engguopeng@buaa.edu.cn>
Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
4 weeks agohw/smbios: allow clearing the VM bit in SMBIOS table 0
Daniil Tatianin [Thu, 24 Jul 2025 19:54:09 +0000 (22:54 +0300)] 
hw/smbios: allow clearing the VM bit in SMBIOS table 0

This is useful to be able to freeze a specific version of SeaBIOS to
prevent guest visible changes between BIOS updates. This is currently
not possible since the extension byte 2 provided by SeaBIOS does not
set the VM bit, whereas QEMU sets it unconditionally.

Allowing to clear it also seems useful if we want to hide the fact that
the guest system is running inside a virtual machine.

Signed-off-by: Daniil Tatianin <d-tatianin@yandex-team.ru>
Reviewed-by: Michael S. Tsirkin <mst@redhat.com>
Message-ID: <20250724195409.43499-1-d-tatianin@yandex-team.ru>
Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
4 weeks agoscripts/ghes_inject: add a script to generate GHES error inject
Mauro Carvalho Chehab [Tue, 23 Sep 2025 07:04:11 +0000 (09:04 +0200)] 
scripts/ghes_inject: add a script to generate GHES error inject

Using the QMP GHESv2 API requires preparing a raw data array
containing a CPER record.

Add a helper script with subcommands to prepare such data.

Currently, only ARM Processor error CPER record is supported, by
using:
$ ghes_inject.py arm

which produces those warnings on Linux:

[  705.032426] [Firmware Warn]: GHES: Unhandled processor error type 0x02: cache error
[  774.866308] {4}[Hardware Error]: Hardware error from APEI Generic Hardware Error Source: 1
[  774.866583] {4}[Hardware Error]: event severity: recoverable
[  774.866738] {4}[Hardware Error]:  Error 0, type: recoverable
[  774.866889] {4}[Hardware Error]:   section_type: ARM processor error
[  774.867048] {4}[Hardware Error]:   MIDR: 0x00000000000f0510
[  774.867189] {4}[Hardware Error]:   running state: 0x0
[  774.867321] {4}[Hardware Error]:   Power State Coordination Interface state: 0
[  774.867511] {4}[Hardware Error]:   Error info structure 0:
[  774.867679] {4}[Hardware Error]:   num errors: 2
[  774.867801] {4}[Hardware Error]:    error_type: 0x02: cache error
[  774.867962] {4}[Hardware Error]:    error_info: 0x000000000091000f
[  774.868124] {4}[Hardware Error]:     transaction type: Data Access
[  774.868280] {4}[Hardware Error]:     cache error, operation type: Data write
[  774.868465] {4}[Hardware Error]:     cache level: 2
[  774.868592] {4}[Hardware Error]:     processor context not corrupted
[  774.868774] [Firmware Warn]: GHES: Unhandled processor error type 0x02: cache error

Such script allows customizing the error data, allowing to change
all fields at the record. Please use:

$ ghes_inject.py arm -h

For more details about its usage.

Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
Reviewed-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Reviewed-by: Michael S. Tsirkin <mst@redhat.com>
Message-ID: <5ea174638e33d23635332fa6d4ae9d751355f127.1758610789.git.mchehab+huawei@kernel.org>
Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
4 weeks agodocs: hest: add new "etc/acpi_table_hest_addr" and update workflow
Mauro Carvalho Chehab [Tue, 23 Sep 2025 07:04:10 +0000 (09:04 +0200)] 
docs: hest: add new "etc/acpi_table_hest_addr" and update workflow

While the HEST layout didn't change, there are some internal
changes related to how offsets are calculated and how memory error
events are triggered.

Update specs to reflect such changes.

Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
Reviewed-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Reviewed-by: Igor Mammedov <imammedo@redhat.com>
Reviewed-by: Michael S. Tsirkin <mst@redhat.com>
Message-ID: <e3e8bd92ce40d997c67ac1d4d973c0041b8f59fc.1758610789.git.mchehab+huawei@kernel.org>
Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
4 weeks agotests/acpi: virt: update HEST and DSDT tables
Mauro Carvalho Chehab [Tue, 23 Sep 2025 07:04:09 +0000 (09:04 +0200)] 
tests/acpi: virt: update HEST and DSDT tables

The following changes for DSDT affecting all files
under tests/data/acpi/aarch64/virt/DSDT* :

    -"tests/data/acpi/aarch64/virt/DSDT",
    -"tests/data/acpi/aarch64/virt/DSDT.acpihmatvirt",
    -"tests/data/acpi/aarch64/virt/DSDT.acpipcihp",
    -"tests/data/acpi/aarch64/virt/DSDT.hpoffacpiindex",
    -"tests/data/acpi/aarch64/virt/DSDT.memhp",
    -"tests/data/acpi/aarch64/virt/DSDT.pxb",
    -"tests/data/acpi/aarch64/virt/DSDT.topology",
    -"tests/data/acpi/aarch64/virt/DSDT.viot",
    -"tests/data/acpi/aarch64/virt/DSDT.smmuv3-dev",
    -"tests/data/acpi/aarch64/virt/DSDT.smmuv3-legacy",

    --- /tmp/DSDT_old.dsl   2025-09-05 15:03:18.964968499 +0200
    +++ /tmp/DSDT.dsl       2025-09-05 15:03:18.966968470 +0200
    @@ -1886,6 +1886,11 @@
                     {
                         Notify (PWRB, 0x80) // Status Change
                     }
    +
    +                If (((Local0 & 0x20) == 0x20))
    +                {
    +                    Notify (GEDD, 0x80) // Status Change
    +                }
                 }
             }

    @@ -1894,6 +1899,12 @@
                 Name (_HID, "PNP0C0C" /* Power Button Device */)  // _HID: Hardware ID
                 Name (_UID, Zero)  // _UID: Unique ID
             }
    +
    +        Device (GEDD)
    +        {
    +            Name (_HID, "PNP0C33" /* Error Device */)  // _HID: Hardware ID
    +            Name (_UID, Zero)  // _UID: Unique ID
    +        }
         }

         Scope (\_SB.PCI0)

Additionally, HEST changes:
    -"tests/data/acpi/aarch64/virt/HEST",

    --- /tmp/HEST_old.dsl   2025-09-05 15:03:19.078653625 +0200
    +++ /tmp/HEST.dsl       2025-09-05 15:03:19.079511472 +0200
    @@ -3,7 +3,7 @@
      * AML/ASL+ Disassembler version 20240322 (64-bit version)
      * Copyright (c) 2000 - 2023 Intel Corporation
      *
    - * Disassembly of /tmp/HEST_old
    + * Disassembly of /tmp/HEST
      *
      * ACPI Data Table [HEST]
      *
    @@ -11,16 +11,16 @@
      */

     [000h 0000 004h]                   Signature : "HEST"    [Hardware Error Source Table]
    -[004h 0004 004h]                Table Length : 00000084
    +[004h 0004 004h]                Table Length : 000000E0
     [008h 0008 001h]                    Revision : 01
    -[009h 0009 001h]                    Checksum : E2
    +[009h 0009 001h]                    Checksum : 6C
     [00Ah 0010 006h]                      Oem ID : "BOCHS "
     [010h 0016 008h]                Oem Table ID : "BXPC    "
     [018h 0024 004h]                Oem Revision : 00000001
     [01Ch 0028 004h]             Asl Compiler ID : "BXPC"
     [020h 0032 004h]       Asl Compiler Revision : 00000001

    -[024h 0036 004h]          Error Source Count : 00000001
    +[024h 0036 004h]          Error Source Count : 00000002

     [028h 0040 002h]               Subtable Type : 000A [Generic Hardware Error Source V2]
     [02Ah 0042 002h]                   Source Id : 0000
    @@ -55,19 +55,62 @@
     [069h 0105 001h]                   Bit Width : 40
     [06Ah 0106 001h]                  Bit Offset : 00
     [06Bh 0107 001h]        Encoded Access Width : 04 [QWord Access:64]
    -[06Ch 0108 008h]                     Address : 0000000043DA0008
    +[06Ch 0108 008h]                     Address : 0000000043DA0010

     [074h 0116 008h]           Read Ack Preserve : FFFFFFFFFFFFFFFE
     [07Ch 0124 008h]              Read Ack Write : 0000000000000001

    -Raw Table Data: Length 132 (0x84)
    +[084h 0132 002h]               Subtable Type : 000A [Generic Hardware Error Source V2]
    +[086h 0134 002h]                   Source Id : 0001
    +[088h 0136 002h]           Related Source Id : FFFF
    +[08Ah 0138 001h]                    Reserved : 00
    +[08Bh 0139 001h]                     Enabled : 01
    +[08Ch 0140 004h]      Records To Preallocate : 00000001
    +[090h 0144 004h]     Max Sections Per Record : 00000001
    +[094h 0148 004h]         Max Raw Data Length : 00000400
    +
    +[098h 0152 00Ch]        Error Status Address : [Generic Address Structure]
    +[098h 0152 001h]                    Space ID : 00 [SystemMemory]
    +[099h 0153 001h]                   Bit Width : 40
    +[09Ah 0154 001h]                  Bit Offset : 00
    +[09Bh 0155 001h]        Encoded Access Width : 04 [QWord Access:64]
    +[09Ch 0156 008h]                     Address : 0000000043DA0008
    +
    +[0A4h 0164 01Ch]                      Notify : [Hardware Error Notification Structure]
    +[0A4h 0164 001h]                 Notify Type : 07 [GPIO]
    +[0A5h 0165 001h]               Notify Length : 1C
    +[0A6h 0166 002h]  Configuration Write Enable : 0000
    +[0A8h 0168 004h]                PollInterval : 00000000
    +[0ACh 0172 004h]                      Vector : 00000000
    +[0B0h 0176 004h]     Polling Threshold Value : 00000000
    +[0B4h 0180 004h]    Polling Threshold Window : 00000000
    +[0B8h 0184 004h]       Error Threshold Value : 00000000
    +[0BCh 0188 004h]      Error Threshold Window : 00000000
    +
    +[0C0h 0192 004h]   Error Status Block Length : 00000400
    +[0C4h 0196 00Ch]           Read Ack Register : [Generic Address Structure]
    +[0C4h 0196 001h]                    Space ID : 00 [SystemMemory]
    +[0C5h 0197 001h]                   Bit Width : 40
    +[0C6h 0198 001h]                  Bit Offset : 00
    +[0C7h 0199 001h]        Encoded Access Width : 04 [QWord Access:64]
    +[0C8h 0200 008h]                     Address : 0000000043DA0018

    -    0000: 48 45 53 54 84 00 00 00 01 E2 42 4F 43 48 53 20  // HEST......BOCHS
    +[0D0h 0208 008h]           Read Ack Preserve : FFFFFFFFFFFFFFFE
    +[0D8h 0216 008h]              Read Ack Write : 0000000000000001
    +
    +Raw Table Data: Length 224 (0xE0)
    +
    +    0000: 48 45 53 54 E0 00 00 00 01 6C 42 4F 43 48 53 20  // HEST.....lBOCHS
         0010: 42 58 50 43 20 20 20 20 01 00 00 00 42 58 50 43  // BXPC    ....BXPC
    -    0020: 01 00 00 00 01 00 00 00 0A 00 00 00 FF FF 00 01  // ................
    +    0020: 01 00 00 00 02 00 00 00 0A 00 00 00 FF FF 00 01  // ................
         0030: 01 00 00 00 01 00 00 00 00 04 00 00 00 40 00 04  // .............@..
         0040: 00 00 DA 43 00 00 00 00 08 1C 00 00 00 00 00 00  // ...C............
         0050: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  // ................
    -    0060: 00 00 00 00 00 04 00 00 00 40 00 04 08 00 DA 43  // .........@.....C
    +    0060: 00 00 00 00 00 04 00 00 00 40 00 04 10 00 DA 43  // .........@.....C
         0070: 00 00 00 00 FE FF FF FF FF FF FF FF 01 00 00 00  // ................
    -    0080: 00 00 00 00                                      // ....
    +    0080: 00 00 00 00 0A 00 01 00 FF FF 00 01 01 00 00 00  // ................
    +    0090: 01 00 00 00 00 04 00 00 00 40 00 04 08 00 DA 43  // .........@.....C
    +    00A0: 00 00 00 00 07 1C 00 00 00 00 00 00 00 00 00 00  // ................
    +    00B0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  // ................
    +    00C0: 00 04 00 00 00 40 00 04 18 00 DA 43 00 00 00 00  // .....@.....C....
    +    00D0: FE FF FF FF FF FF FF FF 01 00 00 00 00 00 00 00  // ................

Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
Reviewed-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Acked-by: Igor Mammedov <imammedo@redhat.com>
Reviewed-by: Michael S. Tsirkin <mst@redhat.com>
Message-ID: <2253eb50df797ab320b4ca610bd22a38e5cfd17a.1758610789.git.mchehab+huawei@kernel.org>
Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
4 weeks agoacpi/generic_event_device.c: enable use_hest_addr for QEMU 10.x
Mauro Carvalho Chehab [Tue, 23 Sep 2025 07:04:08 +0000 (09:04 +0200)] 
acpi/generic_event_device.c: enable use_hest_addr for QEMU 10.x

Now that we have everything in place, enable using HEST GPA
instead of etc/hardware_errors GPA.

Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
Reviewed-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Reviewed-by: Igor Mammedov <imammedo@redhat.com>
Reviewed-by: Michael S. Tsirkin <mst@redhat.com>
Message-ID: <ad77b64aa1f09141efe942539445908631423975.1758610789.git.mchehab+huawei@kernel.org>
Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
4 weeks agoqapi/acpi-hest: add an interface to do generic CPER error injection
Mauro Carvalho Chehab [Tue, 23 Sep 2025 07:04:07 +0000 (09:04 +0200)] 
qapi/acpi-hest: add an interface to do generic CPER error injection

Create a QMP command to be used for generic ACPI APEI hardware error
injection (HEST) via GHESv2, and add support for it for ARM guests.

Error injection uses ACPI_HEST_SRC_ID_QMP source ID to be platform
independent. This is mapped at arch virt bindings, depending on the
types supported by QEMU and by the BIOS. So, on ARM, this is supported
via ACPI_GHES_NOTIFY_GPIO notification type.

This patch was co-authored:
    - original ghes logic to inject a simple ARM record by Shiju Jose;
    - generic logic to handle block addresses by Jonathan Cameron;
    - generic GHESv2 error inject by Mauro Carvalho Chehab;

Co-authored-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Co-authored-by: Shiju Jose <shiju.jose@huawei.com>
Co-authored-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Signed-off-by: Shiju Jose <shiju.jose@huawei.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
Acked-by: Igor Mammedov <imammedo@redhat.com>
Acked-by: Markus Armbruster <armbru@redhat.com>
Reviewed-by: Michael S. Tsirkin <mst@redhat.com>
Message-ID: <81e2118b3c8b7e5da341817f277d61251655e0db.1758610789.git.mchehab+huawei@kernel.org>
Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
4 weeks agoarm/virt: Wire up a GED error device for ACPI / GHES
Mauro Carvalho Chehab [Tue, 23 Sep 2025 07:04:06 +0000 (09:04 +0200)] 
arm/virt: Wire up a GED error device for ACPI / GHES

Adds support to ARM virtualization to allow handling
generic error ACPI Event via GED & error source device.

It is aligned with Linux Kernel patch:
https://lore.kernel.org/lkml/1272350481-27951-8-git-send-email-ying.huang@intel.com/

Co-authored-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
Co-authored-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
Acked-by: Igor Mammedov <imammedo@redhat.com>
Reviewed-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Reviewed-by: Michael S. Tsirkin <mst@redhat.com>
Message-ID: <3237a76b1469d669436399495825348bf34122cd.1758610789.git.mchehab+huawei@kernel.org>
Signed-off-by: Michael S. Tsirkin <mst@redhat.com>