49157207 | 24-Apr-2024 |
Inès Varhol <ines.varhol@telecom-paris.fr> |
hw/arm : Connect DM163 to B-L475E-IOT01A
Signed-off-by: Arnaud Minier <arnaud.minier@telecom-paris.fr> Signed-off-by: Inès Varhol <ines.varhol@telecom-paris.fr> Reviewed-by: Philippe Mathieu-Daudé <
hw/arm : Connect DM163 to B-L475E-IOT01A
Signed-off-by: Arnaud Minier <arnaud.minier@telecom-paris.fr> Signed-off-by: Inès Varhol <ines.varhol@telecom-paris.fr> Reviewed-by: Philippe Mathieu-Daudé <philmd@linaro.org> Message-id: 20240424200929.240921-5-ines.varhol@telecom-paris.fr Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
show more ...
|
4c3308c6 | 24-Apr-2024 |
Inès Varhol <ines.varhol@telecom-paris.fr> |
hw/arm : Create Bl475eMachineState
Signed-off-by: Arnaud Minier <arnaud.minier@telecom-paris.fr> Signed-off-by: Inès Varhol <ines.varhol@telecom-paris.fr> Reviewed-by: Philippe Mathieu-Daudé <philmd
hw/arm : Create Bl475eMachineState
Signed-off-by: Arnaud Minier <arnaud.minier@telecom-paris.fr> Signed-off-by: Inès Varhol <ines.varhol@telecom-paris.fr> Reviewed-by: Philippe Mathieu-Daudé <philmd@linaro.org> Message-id: 20240424200929.240921-4-ines.varhol@telecom-paris.fr Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
show more ...
|
5b5b014b | 24-Apr-2024 |
Inès Varhol <ines.varhol@telecom-paris.fr> |
hw/arm : Pass STM32L4x5 SYSCFG gpios to STM32L4x5 SoC
Exposing SYSCFG inputs to the SoC is practical in order to wire the SoC to the optional DM163 display from the board code (GPIOs outputs need to
hw/arm : Pass STM32L4x5 SYSCFG gpios to STM32L4x5 SoC
Exposing SYSCFG inputs to the SoC is practical in order to wire the SoC to the optional DM163 display from the board code (GPIOs outputs need to be connected to both SYSCFG inputs and DM163 inputs).
STM32L4x5 SYSCFG in-irq interception needed to be changed accordingly.
Signed-off-by: Arnaud Minier <arnaud.minier@telecom-paris.fr> Signed-off-by: Inès Varhol <ines.varhol@telecom-paris.fr> Reviewed-by: Philippe Mathieu-Daudé <philmd@linaro.org> Message-id: 20240424200929.240921-3-ines.varhol@telecom-paris.fr Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
show more ...
|
eb656a60 | 22-Apr-2024 |
Philippe Mathieu-Daudé <philmd@linaro.org> |
hw/arm/npcm7xx: Store derivative OTP fuse key in little endian
Use little endian for derivative OTP fuse key.
Cc: qemu-stable@nongnu.org Fixes: c752bb079b ("hw/nvram: NPCM7xx OTP device model") Sug
hw/arm/npcm7xx: Store derivative OTP fuse key in little endian
Use little endian for derivative OTP fuse key.
Cc: qemu-stable@nongnu.org Fixes: c752bb079b ("hw/nvram: NPCM7xx OTP device model") Suggested-by: Avi Fishman <Avi.Fishman@nuvoton.com> Signed-off-by: Philippe Mathieu-Daudé <philmd@linaro.org> Message-id: 20240422125813.1403-1-philmd@linaro.org Reviewed-by: Peter Maydell <peter.maydell@linaro.org> Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
show more ...
|
88c756bc | 26-Apr-2024 |
Peter Maydell <peter.maydell@linaro.org> |
hw/watchdog/sbsa_gwdt: Make watchdog timer frequency a QOM property
Currently the sbsa_gdwt watchdog device hardcodes its frequency at 62.5MHz. In real hardware, this watchdog is supposed to be driv
hw/watchdog/sbsa_gwdt: Make watchdog timer frequency a QOM property
Currently the sbsa_gdwt watchdog device hardcodes its frequency at 62.5MHz. In real hardware, this watchdog is supposed to be driven from the system counter, which also drives the CPU generic timers. Newer CPU types (in particular from Armv8.6) should have a CPU generic timer frequency of 1GHz, so we can't leave the watchdog on the old QEMU default of 62.5GHz.
Make the frequency a QOM property so it can be set by the board, and have our only board that uses this device set that frequency to the same value it sets the CPU frequency.
Signed-off-by: Peter Maydell <peter.maydell@linaro.org> Reviewed-by: Philippe Mathieu-Daudé <philmd@linaro.org> Message-id: 20240426122913.3427983-4-peter.maydell@linaro.org
show more ...
|
ee4336f9 | 26-Apr-2024 |
Peter Maydell <peter.maydell@linaro.org> |
hw/arm/sbsa-ref: Force CPU generic timer to 62.5MHz
Currently QEMU CPUs always run with a generic timer counter frequency of 62.5MHz, but ARMv8.6 CPUs will run at 1GHz. For older versions of the TF
hw/arm/sbsa-ref: Force CPU generic timer to 62.5MHz
Currently QEMU CPUs always run with a generic timer counter frequency of 62.5MHz, but ARMv8.6 CPUs will run at 1GHz. For older versions of the TF-A firmware that sbsa-ref runs, the frequency of the generic timer is hardcoded into the firmware, and so if the CPU actually has a different frequency then timers in the guest will be set incorrectly.
The default frequency used by the 'max' CPU is about to change, so make the sbsa-ref board force the CPU frequency to the value which the firmware expects.
Newer versions of TF-A will read the frequency from the CPU's CNTFRQ_EL0 register: https://github.com/ARM-software/arm-trusted-firmware/commit/4c77fac98dac0bebc63798aae9101ac865b87148 so in the longer term we could make this board use the 1GHz frequency. We will need to make sure we update the binaries used by our avocado test Aarch64SbsarefMachine.test_sbsaref_alpine_linux_max_pauth_impdef before we can do that.
Signed-off-by: Peter Maydell <peter.maydell@linaro.org> Reviewed-by: Philippe Mathieu-Daudé <philmd@linaro.org> Reviewed-by: Marcin Juszkiewicz <marcin.juszkiewicz@linaro.org> Message-id: 20240426122913.3427983-3-peter.maydell@linaro.org
show more ...
|
259181d2 | 15-Apr-2024 |
Thomas Huth <thuth@redhat.com> |
hw: Add a Kconfig switch for the TYPE_CPU_CLUSTER device
The cpu-cluster device is only needed for some few arm and riscv machines. Let's avoid compiling and linking it if it is not really necessary
hw: Add a Kconfig switch for the TYPE_CPU_CLUSTER device
The cpu-cluster device is only needed for some few arm and riscv machines. Let's avoid compiling and linking it if it is not really necessary.
Reviewed-by: Philippe Mathieu-Daudé <philmd@linaro.org> Signed-off-by: Thomas Huth <thuth@redhat.com> Message-ID: <20240415065655.130099-3-thuth@redhat.com> Reviewed-by: Richard Henderson <richard.henderson@linaro.org> Signed-off-by: Philippe Mathieu-Daudé <philmd@linaro.org>
show more ...
|
c1c350dc | 15-Apr-2024 |
Thomas Huth <thuth@redhat.com> |
hw: Fix problem with the A*MPCORE switches in the Kconfig files
A9MPCORE, ARM11MPCORE and A15MPCORE are defined twice, once in hw/cpu/Kconfig and once in hw/arm/Kconfig. This is only possible by acc
hw: Fix problem with the A*MPCORE switches in the Kconfig files
A9MPCORE, ARM11MPCORE and A15MPCORE are defined twice, once in hw/cpu/Kconfig and once in hw/arm/Kconfig. This is only possible by accident, since hw/cpu/Kconfig is never included from hw/Kconfig. Fix it by declaring the switches only in hw/cpu/Kconfig (since the related files reside in the hw/cpu/ folder) and by making sure that the file hw/cpu/Kconfig is now properly included from hw/Kconfig.
Reviewed-by: Philippe Mathieu-Daudé <philmd@linaro.org> Signed-off-by: Thomas Huth <thuth@redhat.com> Message-ID: <20240415065655.130099-2-thuth@redhat.com> Reviewed-by: Richard Henderson <richard.henderson@linaro.org> Signed-off-by: Philippe Mathieu-Daudé <philmd@linaro.org>
show more ...
|
92741432 | 29-Mar-2024 |
Arnaud Minier <arnaud.minier@telecom-paris.fr> |
hw/arm: Add the USART to the stm32l4x5 SoC
Add the USART to the SoC and connect it to the other implemented devices.
Signed-off-by: Arnaud Minier <arnaud.minier@telecom-paris.fr> Signed-off-by: Inè
hw/arm: Add the USART to the stm32l4x5 SoC
Add the USART to the SoC and connect it to the other implemented devices.
Signed-off-by: Arnaud Minier <arnaud.minier@telecom-paris.fr> Signed-off-by: Inès Varhol <ines.varhol@telecom-paris.fr> Reviewed-by: Peter Maydell <peter.maydell@linaro.org> Message-id: 20240329174402.60382-5-arnaud.minier@telecom-paris.fr [PMM: fixed a few checkpatch nits] Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
show more ...
|
ad80e367 | 12-Apr-2024 |
Peter Maydell <peter.maydell@linaro.org> |
hw, target: Add ResetType argument to hold and exit phase methods
We pass a ResetType argument to the Resettable class enter phase method, but we don't pass it to hold and exit, even though the call
hw, target: Add ResetType argument to hold and exit phase methods
We pass a ResetType argument to the Resettable class enter phase method, but we don't pass it to hold and exit, even though the callsites have it readily available. This means that if a device cared about the ResetType it would need to record it in the enter phase method to use later on. Pass the type to all three of the phase methods to avoid having to do that.
Commit created with
for dir in hw target include; do \ spatch --macro-file scripts/cocci-macro-file.h \ --sp-file scripts/coccinelle/reset-type.cocci \ --keep-comments --smpl-spacing --in-place \ --include-headers --dir $dir; done
and no manual edits.
Signed-off-by: Peter Maydell <peter.maydell@linaro.org> Reviewed-by: Edgar E. Iglesias <edgar.iglesias@amd.com> Reviewed-by: Richard Henderson <richard.henderson@linaro.org> Reviewed-by: Luc Michel <luc.michel@amd.com> Message-id: 20240412160809.1260625-5-peter.maydell@linaro.org
show more ...
|
5ae47f7a | 19-Apr-2024 |
Jinjie Ruan <ruanjinjie@huawei.com> |
hw/arm/virt: Enable NMI support in the GIC if the CPU has FEAT_NMI
If the CPU implements FEAT_NMI, then turn on the NMI support in the GICv3 too. It's permitted to have a configuration with FEAT_NM
hw/arm/virt: Enable NMI support in the GIC if the CPU has FEAT_NMI
If the CPU implements FEAT_NMI, then turn on the NMI support in the GICv3 too. It's permitted to have a configuration with FEAT_NMI in the CPU (and thus NMI support in the CPU interfaces too) but no NMI support in the distributor and redistributor, but this isn't a very useful setup as it's close to having no NMI support at all.
We don't need to gate the enabling of NMI in the GIC behind a machine version property, because none of our current CPUs implement FEAT_NMI, and '-cpu max' is not something we maintain migration compatibility across versions for. So we can always enable the GIC NMI support when the CPU has it.
Neither hvf nor KVM support NMI in the GIC yet, so we don't enable it unless we're using TCG.
Signed-off-by: Jinjie Ruan <ruanjinjie@huawei.com> Reviewed-by: Richard Henderson <richard.henderson@linaro.org> Message-id: 20240407081733.3231820-25-ruanjinjie@huawei.com [PMM: Update comment and commit message] Suggested-by: Peter Maydell <peter.maydell@linaro.org> Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
show more ...
|
34d94b7a | 19-Apr-2024 |
Jinjie Ruan <ruanjinjie@huawei.com> |
hw/arm/virt: Wire NMI and VINMI irq lines from GIC to CPU
Wire the new NMI and VINMI interrupt line from the GIC to each CPU if it is not GICv2.
Signed-off-by: Jinjie Ruan <ruanjinjie@huawei.com> R
hw/arm/virt: Wire NMI and VINMI irq lines from GIC to CPU
Wire the new NMI and VINMI interrupt line from the GIC to each CPU if it is not GICv2.
Signed-off-by: Jinjie Ruan <ruanjinjie@huawei.com> Reviewed-by: Richard Henderson <richard.henderson@linaro.org> Message-id: 20240407081733.3231820-12-ruanjinjie@huawei.com Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
show more ...
|
85fa9acd | 25-Mar-2024 |
Paolo Bonzini <pbonzini@redhat.com> |
hw: Add compat machines for 9.1
Add 9.1 machine types for arm/i440fx/m68k/q35/s390x/spapr.
Reviewed-by: Cornelia Huck <cohuck@redhat.com> Acked-by: Thomas Huth <thuth@redhat.com> Reviewed-by: Harsh
hw: Add compat machines for 9.1
Add 9.1 machine types for arm/i440fx/m68k/q35/s390x/spapr.
Reviewed-by: Cornelia Huck <cohuck@redhat.com> Acked-by: Thomas Huth <thuth@redhat.com> Reviewed-by: Harsh Prateek Bora <harshpb@linux.ibm.com> Reviewed-by: Zhao Liu <zhao1.liu@intel.com> Cc: Gavin Shan <gshan@redhat.com> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
show more ...
|
0b796f38 | 13-Mar-2024 |
Philippe Mathieu-Daudé <philmd@linaro.org> |
hw/arm/smmu: Avoid using inlined functions with external linkage again
Similarly to commit 9de9fa5cf2 ("hw/arm/smmu-common: Avoid using inlined functions with external linkage"):
None of our code
hw/arm/smmu: Avoid using inlined functions with external linkage again
Similarly to commit 9de9fa5cf2 ("hw/arm/smmu-common: Avoid using inlined functions with external linkage"):
None of our code base require / use inlined functions with external linkage. Some places use internal inlining in the hot path. These two functions are certainly not in any hot path and don't justify any inlining, so these are likely oversights rather than intentional.
Fix:
C compiler for the host machine: clang (clang 15.0.0 "Apple clang version 15.0.0 (clang-1500.3.9.4)") ... hw/arm/smmu-common.c:203:43: error: static function 'smmu_hash_remove_by_vmid' is used in an inline function with external linkage [-Werror,-Wstatic-in-inline] g_hash_table_foreach_remove(s->iotlb, smmu_hash_remove_by_vmid, &vmid); ^ include/hw/arm/smmu-common.h:197:1: note: use 'static' to give inline function 'smmu_iotlb_inv_vmid' internal linkage void smmu_iotlb_inv_vmid(SMMUState *s, uint16_t vmid); ^ static hw/arm/smmu-common.c:139:17: note: 'smmu_hash_remove_by_vmid' declared here static gboolean smmu_hash_remove_by_vmid(gpointer key, gpointer value, ^
Fixes: ccc3ee3871 ("hw/arm/smmuv3: Add CMDs related to stage-2") Signed-off-by: Philippe Mathieu-Daudé <philmd@linaro.org> Reviewed-by: Richard Henderson <richard.henderson@linaro.org> Reviewed-by: Eric Auger <eric.auger@redhat.com> Message-Id: <20240313184954.42513-2-philmd@linaro.org>
show more ...
|
393770d7 | 29-Mar-2024 |
Cédric Le Goater <clg@redhat.com> |
raspi4b: Reduce RAM to 1Gb on 32-bit hosts
Change the board revision number and RAM size to 1Gb on 32-bit hosts. On these systems, RAM has a 2047 MB limit and this breaks the tests.
Fixes: 7785e8ea
raspi4b: Reduce RAM to 1Gb on 32-bit hosts
Change the board revision number and RAM size to 1Gb on 32-bit hosts. On these systems, RAM has a 2047 MB limit and this breaks the tests.
Fixes: 7785e8ea2204 ("hw/arm: Introduce Raspberry PI 4 machine") Signed-off-by: Cédric Le Goater <clg@redhat.com> Message-id: 20240329150155.357043-1-clg@redhat.com Reviewed-by: Peter Maydell <peter.maydell@linaro.org> Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
show more ...
|
6328d8ff | 25-Mar-2024 |
Cédric Le Goater <clg@redhat.com> |
misc/pca955*: Move models under hw/gpio
The PCA9552 and PCA9554 devices are both I2C GPIO controllers and the PCA9552 also can drive LEDs. Do all the necessary adjustments to move the models under h
misc/pca955*: Move models under hw/gpio
The PCA9552 and PCA9554 devices are both I2C GPIO controllers and the PCA9552 also can drive LEDs. Do all the necessary adjustments to move the models under hw/gpio.
Cc: Glenn Miles <milesg@linux.vnet.ibm.com> Signed-off-by: Cédric Le Goater <clg@redhat.com> Message-ID: <20240325134833.1484265-1-clg@redhat.com> Reviewed-by: Thomas Huth <thuth@redhat.com> Signed-off-by: Thomas Huth <thuth@redhat.com>
show more ...
|
1967e9e0 | 19-Mar-2024 |
Cédric Le Goater <clg@redhat.com> |
aspeed: Make the ast1030-a1 SoC not user creatable
Aspeed SoCs are complex devices that can not be specified on the command line. Fix that to avoid QEMU aborts.
Resolves: https://gitlab.com/qemu-pr
aspeed: Make the ast1030-a1 SoC not user creatable
Aspeed SoCs are complex devices that can not be specified on the command line. Fix that to avoid QEMU aborts.
Resolves: https://gitlab.com/qemu-project/qemu/-/issues/2227 Fixes: 356b230ed138 ("aspeed/soc : Add AST1030 support") Reported-by: Thomas Huth <thuth@redhat.com> Signed-off-by: Cédric Le Goater <clg@redhat.com> Reviewed-by: Philippe Mathieu-Daudé <philmd@linaro.org> Message-ID: <20240319150903.413662-2-clg@redhat.com> Signed-off-by: Thomas Huth <thuth@redhat.com>
show more ...
|
ed6d5c2e | 19-Mar-2024 |
Cédric Le Goater <clg@redhat.com> |
aspeed: Make the ast2600-a3 SoC not user creatable
Aspeed SoCs are complex devices that can not be specified on the command line. Fix that to avoid QEMU aborts.
Resolves: https://gitlab.com/qemu-pr
aspeed: Make the ast2600-a3 SoC not user creatable
Aspeed SoCs are complex devices that can not be specified on the command line. Fix that to avoid QEMU aborts.
Resolves: https://gitlab.com/qemu-project/qemu/-/issues/2227 Fixes: f25c0ae1079d ("aspeed/soc: Add AST2600 support") Reported-by: Thomas Huth <thuth@redhat.com> Signed-off-by: Cédric Le Goater <clg@redhat.com> Reviewed-by: Philippe Mathieu-Daudé <philmd@linaro.org> Message-ID: <20240319150903.413662-1-clg@redhat.com> Signed-off-by: Thomas Huth <thuth@redhat.com>
show more ...
|
a7538ca0 | 19-Mar-2024 |
Cédric Le Goater <clg@redhat.com> |
aspeed/smc: Only wire flash devices at reset
The Aspeed machines have many Static Memory Controllers (SMC), up to 8, which can only drive flash memory devices. Commit 27a2c66c92ec ("aspeed/smc: Wire
aspeed/smc: Only wire flash devices at reset
The Aspeed machines have many Static Memory Controllers (SMC), up to 8, which can only drive flash memory devices. Commit 27a2c66c92ec ("aspeed/smc: Wire CS lines at reset") tried to ease the definitions of these devices by allowing flash devices from the command line to be attached to a SSI bus. For that, the wiring of the CS lines of the Aspeed SMC controller was moved at reset. Two assumptions are made though, first that the device has a SSI_GPIO_CS GPIO line, which is not always the case, and second that it is a flash device.
Correct this problem by ensuring that the devices attached to the bus are of the correct flash type. This fixes a QEMU abort when devices without a CS line, such as the max111x, are passed on the command line.
While at it, export TYPE_M25P80 used in the Xilinx Versal Virtual machine.
Resolves: https://gitlab.com/qemu-project/qemu/-/issues/2228 Fixes: 27a2c66c92ec ("aspeed/smc: Wire CS lines at reset") Reported-by: Thomas Huth <thuth@redhat.com> Reviewed-by: Thomas Huth <thuth@redhat.com> Tested-by: Thomas Huth <thuth@redhat.com> [ clg: minor fixes in the commit log ] Signed-off-by: Cédric Le Goater <clg@redhat.com>
show more ...
|
69ea07a5 | 14-Mar-2024 |
Igor Mammedov <imammedo@redhat.com> |
smbios: get rid of global smbios_ep_type
Signed-off-by: Igor Mammedov <imammedo@redhat.com> Acked-by: Daniel Henrique Barboza <dbarboza@ventanamicro.com> Reviewed-by: Ani Sinha <anisinha@redhat.com>
smbios: get rid of global smbios_ep_type
Signed-off-by: Igor Mammedov <imammedo@redhat.com> Acked-by: Daniel Henrique Barboza <dbarboza@ventanamicro.com> Reviewed-by: Ani Sinha <anisinha@redhat.com> Tested-by: Fiona Ebner <f.ebner@proxmox.com> Message-Id: <20240314152302.2324164-14-imammedo@redhat.com> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
show more ...
|
b3854ce8 | 14-Mar-2024 |
Igor Mammedov <imammedo@redhat.com> |
smbios: get rid of smbios_legacy global
clean up smbios_set_defaults() which is reused by legacy and non legacy machines from being aware of 'legacy' notion and need to turn it off. And push legacy
smbios: get rid of smbios_legacy global
clean up smbios_set_defaults() which is reused by legacy and non legacy machines from being aware of 'legacy' notion and need to turn it off. And push legacy handling up to PC machine code where it's relevant.
Signed-off-by: Igor Mammedov <imammedo@redhat.com> Reviewed-by: Ani Sinha <anisinha@redhat.com> Acked-by: Daniel Henrique Barboza <dbarboza@ventanamicro.com> Tested-by: Fiona Ebner <f.ebner@proxmox.com> Message-Id: <20240314152302.2324164-7-imammedo@redhat.com> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
show more ...
|
62d77600 | 07-Mar-2024 |
Eric Auger <eric.auger@redhat.com> |
hw/arm/virt: Set virtio-iommu aw-bits default value to 48
On ARM we set 48b as a default (matching SMMUv3 SMMU_IDR5.VAX == 0).
hw_compat_8_2 is used to handle the compatibility for machine types be
hw/arm/virt: Set virtio-iommu aw-bits default value to 48
On ARM we set 48b as a default (matching SMMUv3 SMMU_IDR5.VAX == 0).
hw_compat_8_2 is used to handle the compatibility for machine types before 9.0 (default was 64 bits).
Signed-off-by: Eric Auger <eric.auger@redhat.com> Reviewed-by: Zhenzhong Duan <Zhenzhong.duan@intel.com> Message-Id: <20240307134445.92296-9-eric.auger@redhat.com> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
show more ...
|
0a5b5acd | 08-Mar-2024 |
Ankit Agrawal <ankita@nvidia.com> |
hw/acpi: Implement the SRAT GI affinity structure
ACPI spec provides a scheme to associate "Generic Initiators" [1] (e.g. heterogeneous processors and accelerators, GPUs, and I/O devices with integr
hw/acpi: Implement the SRAT GI affinity structure
ACPI spec provides a scheme to associate "Generic Initiators" [1] (e.g. heterogeneous processors and accelerators, GPUs, and I/O devices with integrated compute or DMA engines GPUs) with Proximity Domains. This is achieved using Generic Initiator Affinity Structure in SRAT. During bootup, Linux kernel parse the ACPI SRAT to determine the PXM ids and create a NUMA node for each unique PXM ID encountered. Qemu currently do not implement these structures while building SRAT.
Add GI structures while building VM ACPI SRAT. The association between device and node are stored using acpi-generic-initiator object. Lookup presence of all such objects and use them to build these structures.
The structure needs a PCI device handle [2] that consists of the device BDF. The vfio-pci device corresponding to the acpi-generic-initiator object is located to determine the BDF.
[1] ACPI Spec 6.3, Section 5.2.16.6 [2] ACPI Spec 6.3, Table 5.80
Cc: Jonathan Cameron <qemu-devel@nongnu.org> Cc: Alex Williamson <alex.williamson@redhat.com> Cc: Cedric Le Goater <clg@redhat.com> Reviewed-by: Jonathan Cameron <Jonathan.Cameron@huawei.com> Signed-off-by: Ankit Agrawal <ankita@nvidia.com> Message-Id: <20240308145525.10886-3-ankita@nvidia.com> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
show more ...
|
a2531bb8 | 08-Mar-2024 |
Peter Maydell <peter.maydell@linaro.org> |
hw/arm: Deprecate various old Arm machine types
QEMU includes some models of old Arm machine types which are a bit problematic for us because: * they're written in a very old way that uses numerous
hw/arm: Deprecate various old Arm machine types
QEMU includes some models of old Arm machine types which are a bit problematic for us because: * they're written in a very old way that uses numerous APIs that we would like to get away from (eg they don't use qdev, they use qemu_system_reset_request(), they use vmstate_register(), etc) * they've been that way for a decade plus and nobody particularly has stepped up to try to modernise the code (beyond some occasional work here and there) * we often don't have test cases for them, which means that if we do try to do the necessary refactoring work on them we have no idea if they even still work at all afterwards
All these machine types are also of hardware that has largely passed away into history and where I would not be surprised to find that e.g. the Linux kernel support was never tested on real hardware any more.
After some consultation with the Linux kernel developers, we are going to deprecate:
All PXA2xx machines:
akita Sharp SL-C1000 (Akita) PDA (PXA270) borzoi Sharp SL-C3100 (Borzoi) PDA (PXA270) connex Gumstix Connex (PXA255) mainstone Mainstone II (PXA27x) spitz Sharp SL-C3000 (Spitz) PDA (PXA270) terrier Sharp SL-C3200 (Terrier) PDA (PXA270) tosa Sharp SL-6000 (Tosa) PDA (PXA255) verdex Gumstix Verdex Pro XL6P COMs (PXA270) z2 Zipit Z2 (PXA27x)
All OMAP2 machines:
n800 Nokia N800 tablet aka. RX-34 (OMAP2420) n810 Nokia N810 tablet aka. RX-44 (OMAP2420)
One of the OMAP1 machines:
cheetah Palm Tungsten|E aka. Cheetah PDA (OMAP310)
Rationale: * for QEMU dropping individual machines is much less beneficial than if we can drop support for an entire SoC * the OMAP2 QEMU code in particular is large, old and unmaintained, and none of the OMAP2 kernel maintainers said they were using QEMU in any of their testing/development * although there is a setup that is booting test kernels on some of the PXA2xx machines, nobody seemed to be using them as part of their active kernel development and my impression from the email thread is that PXA is the closest of all these SoC families to being dropped from the kernel soon * nobody said they were using cheetah, so it's entirely untested and quite probably broken * on the other hand the OMAP1 sx1 model does seem to be being used as part of kernel development, and there was interest in keeping collie around
In particular, the mainstone, tosa and z2 machine types have already been dropped from Linux.
Mark all these machine types as deprecated.
Signed-off-by: Peter Maydell <peter.maydell@linaro.org> Reviewed-by: Richard Henderson <richard.henderson@linaro.org> Reviewed-by: Thomas Huth <thuth@redhat.com> Reviewed-by: Philippe Mathieu-Daudé <philmd@linaro.org> Message-id: 20240308171621.3749894-1-peter.maydell@linaro.org
show more ...
|
b934c3fa | 14-Nov-2023 |
Philippe Mathieu-Daudé <philmd@linaro.org> |
hw/xen: Rename 'ram_memory' global variable as 'xen_memory'
To avoid a potential global variable shadow in hw/i386/pc_piix.c::pc_init1(), rename Xen's "ram_memory" as "xen_memory".
Signed-off-by: P
hw/xen: Rename 'ram_memory' global variable as 'xen_memory'
To avoid a potential global variable shadow in hw/i386/pc_piix.c::pc_init1(), rename Xen's "ram_memory" as "xen_memory".
Signed-off-by: Philippe Mathieu-Daudé <philmd@linaro.org> Reviewed-by: David Woodhouse <dwmw@amazon.co.uk> Message-Id: <20231114143816.71079-11-philmd@linaro.org>
show more ...
|