aboutsummaryrefslogtreecommitdiff
path: root/hw/arm/virt.c
AgeCommit message (Collapse)Author
2022-05-19hw/arm/virt: Drop #size-cells and #address-cells from gpio-keys dtb nodePeter Maydell
The virt board generates a gpio-keys node in the dtb, but it incorrectly gives this node #size-cells and #address-cells properties. If you dump the dtb with 'machine dumpdtb=file.dtb' and run it through dtc, dtc will warn about this: Warning (avoid_unnecessary_addr_size): /gpio-keys: unnecessary #address-cells/#size-cells without "ranges" or child "reg" property Remove the bogus properties. Signed-off-by: Peter Maydell <peter.maydell@linaro.org> Reviewed-by: Richard Henderson <richard.henderson@linaro.org> Message-id: 20220513131316.4081539-3-peter.maydell@linaro.org
2022-05-19hw/arm/virt: Fix incorrect non-secure flash dtb node namePeter Maydell
In the virt board with secure=on we put two nodes in the dtb for flash devices: one for the secure-only flash, and one for the non-secure flash. We get the reg properties for these correct, but in the DT node name, which by convention includes the base address of devices, we used the wrong address. Fix it. Spotted by dtc, which will complain Warning (unique_unit_address): /flash@0: duplicate unit-address (also used in node /secflash@0) if you dump the dtb from QEMU with -machine dumpdtb=file.dtb and then decompile it with dtc. Signed-off-by: Peter Maydell <peter.maydell@linaro.org> Reviewed-by: Richard Henderson <richard.henderson@linaro.org> Message-id: 20220513131316.4081539-2-peter.maydell@linaro.org
2022-05-09hw/arm/virt: Fix CPU's default NUMA node IDGavin Shan
When CPU-to-NUMA association isn't explicitly provided by users, the default one is given by mc->get_default_cpu_node_id(). However, the CPU topology isn't fully considered in the default association and this causes CPU topology broken warnings on booting Linux guest. For example, the following warning messages are observed when the Linux guest is booted with the following command lines. /home/gavin/sandbox/qemu.main/build/qemu-system-aarch64 \ -accel kvm -machine virt,gic-version=host \ -cpu host \ -smp 6,sockets=2,cores=3,threads=1 \ -m 1024M,slots=16,maxmem=64G \ -object memory-backend-ram,id=mem0,size=128M \ -object memory-backend-ram,id=mem1,size=128M \ -object memory-backend-ram,id=mem2,size=128M \ -object memory-backend-ram,id=mem3,size=128M \ -object memory-backend-ram,id=mem4,size=128M \ -object memory-backend-ram,id=mem4,size=384M \ -numa node,nodeid=0,memdev=mem0 \ -numa node,nodeid=1,memdev=mem1 \ -numa node,nodeid=2,memdev=mem2 \ -numa node,nodeid=3,memdev=mem3 \ -numa node,nodeid=4,memdev=mem4 \ -numa node,nodeid=5,memdev=mem5 : alternatives: patching kernel code BUG: arch topology borken the CLS domain not a subset of the MC domain <the above error log repeats> BUG: arch topology borken the DIE domain not a subset of the NODE domain With current implementation of mc->get_default_cpu_node_id(), CPU#0 to CPU#5 are associated with NODE#0 to NODE#5 separately. That's incorrect because CPU#0/1/2 should be associated with same NUMA node because they're seated in same socket. This fixes the issue by considering the socket ID when the default CPU-to-NUMA association is provided in virt_possible_cpu_arch_ids(). With this applied, no more CPU topology broken warnings are seen from the Linux guest. The 6 CPUs are associated with NODE#0/1, but there are no CPUs associated with NODE#2/3/4/5. Signed-off-by: Gavin Shan <gshan@redhat.com> Reviewed-by: Igor Mammedov <imammedo@redhat.com> Reviewed-by: Yanan Wang <wangyanan55@huawei.com> Message-id: 20220503140304.855514-6-gshan@redhat.com Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
2022-05-09hw/arm/virt: Consider SMP configuration in CPU topologyGavin Shan
Currently, the SMP configuration isn't considered when the CPU topology is populated. In this case, it's impossible to provide the default CPU-to-NUMA mapping or association based on the socket ID of the given CPU. This takes account of SMP configuration when the CPU topology is populated. The die ID for the given CPU isn't assigned since it's not supported on arm/virt machine. Besides, the used SMP configuration in qtest/numa-test/aarch64_numa_cpu() is corrcted to avoid testing failure Signed-off-by: Gavin Shan <gshan@redhat.com> Reviewed-by: Yanan Wang <wangyanan55@huawei.com> Acked-by: Igor Mammedov <imammedo@redhat.com> Message-id: 20220503140304.855514-4-gshan@redhat.com Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
2022-05-09target/arm: Define neoverse-n1Richard Henderson
Enable the n1 for virt and sbsa board use. Reviewed-by: Peter Maydell <peter.maydell@linaro.org> Signed-off-by: Richard Henderson <richard.henderson@linaro.org> Message-id: 20220506180242.216785-25-richard.henderson@linaro.org Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
2022-05-09target/arm: Define cortex-a76Richard Henderson
Enable the a76 for virt and sbsa board use. Reviewed-by: Peter Maydell <peter.maydell@linaro.org> Signed-off-by: Richard Henderson <richard.henderson@linaro.org> Message-id: 20220506180242.216785-24-richard.henderson@linaro.org Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
2022-04-29hw/core: Move the ARM sysbus-fdt to coreAlistair Francis
The ARM virt machine currently uses sysbus-fdt to create device tree entries for dynamically created MMIO devices. The RISC-V virt machine can also benefit from this, so move the code to the core directory. Signed-off-by: Alistair Francis <alistair.francis@wdc.com> Reviewed-by: Edgar E. Iglesias <edgar.iglesias@amd.com> Reviewed-by: Bin Meng <bmeng.cn@gmail.com> Message-Id: <20220427234146.1130752-3-alistair.francis@opensource.wdc.com> Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
2022-04-22hw/arm/virt: Support TCG GICv4Peter Maydell
Add support for the TCG GICv4 to the virt board. For the board, the GICv4 is very similar to the GICv3, with the only difference being the size of the redistributor frame. The changes here are thus: * calculating virt_redist_capacity correctly for GICv4 * changing various places which were "if GICv3" to be "if not GICv2" * the commandline option handling Note that using GICv4 reduces the maximum possible number of CPUs on the virt board from 512 to 317, because we can now only fit half as many redistributors into the redistributor regions we have defined. Signed-off-by: Peter Maydell <peter.maydell@linaro.org> Reviewed-by: Richard Henderson <richard.henderson@linaro.org> Message-id: 20220408141550.1271295-42-peter.maydell@linaro.org
2022-04-22hw/arm/virt: Abstract out calculation of redistributor region capacityPeter Maydell
In several places in virt.c we calculate the number of redistributors that fit in a region of our memory map, which is the size of the region divided by the size of a single redistributor frame. For GICv4, the redistributor frame is a different size from that for GICv3. Abstract out the calculation of redistributor region capacity so that we have one place we need to change to handle GICv4 rather than several. Signed-off-by: Peter Maydell <peter.maydell@linaro.org> Reviewed-by: Richard Henderson <richard.henderson@linaro.org> Message-id: 20220408141550.1271295-41-peter.maydell@linaro.org
2022-04-22hw/arm/virt: Use VIRT_GIC_VERSION_* enum values in create_gic()Peter Maydell
Everywhere we need to check which GIC version we're using, we look at vms->gic_version and use the VIRT_GIC_VERSION_* enum values, except in create_gic(), which copies vms->gic_version into a local 'int' variable and makes direct comparisons against values 2 and 3. For consistency, change this function to check the GIC version the same way we do elsewhere. This includes not implicitly relying on the enumeration type values happening to match the integer 'revision' values the GIC device object wants. Signed-off-by: Peter Maydell <peter.maydell@linaro.org> Reviewed-by: Richard Henderson <richard.henderson@linaro.org> Message-id: 20220408141550.1271295-40-peter.maydell@linaro.org
2022-04-21hw/arm/virt: Check for attempt to use TrustZone with KVM or HVFPeter Maydell
It's not possible to provide the guest with the Security extensions (TrustZone) when using KVM or HVF, because the hardware virtualization extensions don't permit running EL3 guest code. However, we weren't checking for this combination, with the result that QEMU would assert if you tried it: $ qemu-system-aarch64 -enable-kvm -machine virt,secure=on -cpu host -display none Unexpected error in object_property_find_err() at ../../qom/object.c:1304: qemu-system-aarch64: Property 'host-arm-cpu.secure-memory' not found Aborted Check for this combination of options and report an error, in the same way we already do for attempts to give a KVM or HVF guest the Virtualization or MTE extensions. Now we will report: qemu-system-aarch64: mach-virt: KVM does not support providing Security extensions (TrustZone) to the guest CPU Resolves: https://gitlab.com/qemu-project/qemu/-/issues/961 Signed-off-by: Peter Maydell <peter.maydell@linaro.org> Reviewed-by: Richard Henderson <richard.henderson@linaro.org> Message-id: 20220404155301.566542-1-peter.maydell@linaro.org
2022-04-20hw: Add compat machines for 7.1Cornelia Huck
Add 7.1 machine types for arm/i440fx/m68k/q35/s390x/spapr. Signed-off-by: Cornelia Huck <cohuck@redhat.com> Message-Id: <20220316145521.1224083-1-cohuck@redhat.com> Reviewed-by: Eric Farman <farman@linux.ibm.com> Reviewed-by: Cédric Le Goater <clg@kaod.org> Acked-by: Laurent Vivier <laurent@vivier.eu> Reviewed-by: Eric Auger <eric.auger@redhat.com> Reviewed-by: Yanan Wang <wangyanan55@huawei.com> Signed-off-by: Thomas Huth <thuth@redhat.com>
2022-03-18hw/arm/virt: Fix gic-version=max when CONFIG_ARM_GICV3_TCG is unsetEric Auger
In TCG mode, if gic-version=max we always select GICv3 even if CONFIG_ARM_GICV3_TCG is unset. We shall rather select GICv2. This also brings the benefit of fixing qos tests errors for tests using gic-version=max with CONFIG_ARM_GICV3_TCG unset. Signed-off-by: Eric Auger <eric.auger@redhat.com> Reviewed-by: Andrew Jones <drjones@redhat.com> Message-id: 20220308182452.223473-3-eric.auger@redhat.com Reviewed-by: Peter Maydell <peter.maydell@linaro.org> Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
2022-03-07hw/arm/virt: Disable LPA2 for -machine virt-6.2Richard Henderson
There is a Linux kernel bug present until v5.12 that prevents booting with FEAT_LPA2 enabled. As a workaround for TCG, disable this feature for machine versions prior to 7.0. Cc: Daniel P. Berrangé <berrange@redhat.com> Signed-off-by: Richard Henderson <richard.henderson@linaro.org> Signed-off-by: Peter Maydell <peter.maydell@linaro.org> Reviewed-by: Peter Maydell <peter.maydell@linaro.org>
2022-02-08hw/arm/boot: Drop nb_cpus field from arm_boot_infoPeter Maydell
We use the arm_boot_info::nb_cpus field in only one place, and that place can easily get the number of CPUs locally rather than relying on the board code to have set the field correctly. (At least one board, xlnx-versal-virt, does not set the field despite having more than one CPU.) Signed-off-by: Peter Maydell <peter.maydell@linaro.org> Reviewed-by: Richard Henderson <richard.henderson@linaro.org> Reviewed-by: Niek Linnenbank <nieklinnenbank@gmail.com> Tested-by: Cédric Le Goater <clg@kaod.org> Tested-by: Niek Linnenbank <nieklinnenbank@gmail.com> Message-id: 20220127154639.2090164-16-peter.maydell@linaro.org
2022-02-08hw/arm/virt: Let boot.c handle PSCI enablementPeter Maydell
Instead of setting the CPU psci-conduit and start-powered-off properties in the virt board code, set the arm_boot_info psci_conduit field so that the boot.c code can do it. This will fix a corner case where we were incorrectly enabling PSCI emulation when booting guest code into EL3 because it was an ELF file passed to -kernel or to the generic loader. (EL3 guest code started via -bios or -pflash was already being run with PSCI emulation disabled.) Signed-off-by: Peter Maydell <peter.maydell@linaro.org> Reviewed-by: Richard Henderson <richard.henderson@linaro.org> Reviewed-by: Niek Linnenbank <nieklinnenbank@gmail.com> Tested-by: Cédric Le Goater <clg@kaod.org> Tested-by: Niek Linnenbank <nieklinnenbank@gmail.com> Message-id: 20220127154639.2090164-9-peter.maydell@linaro.org
2022-01-20hw/arm/virt: Drop superfluous checks against highmemMarc Zyngier
Now that the devices present in the extended memory map are checked against the available PA space and disabled when they don't fit, there is no need to keep the same checks against highmem, as highmem really is a shortcut for the PA space being 32bit. Reviewed-by: Eric Auger <eric.auger@redhat.com> Signed-off-by: Marc Zyngier <maz@kernel.org> Message-id: 20220114140741.1358263-7-maz@kernel.org Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
2022-01-20hw/arm/virt: Disable highmem devices that don't fit in the PA rangeMarc Zyngier
In order to only keep the highmem devices that actually fit in the PA range, check their location against the range and update highest_gpa if they fit. If they don't, mark them as disabled. Signed-off-by: Marc Zyngier <maz@kernel.org> Reviewed-by: Eric Auger <eric.auger@redhat.com> Message-id: 20220114140741.1358263-6-maz@kernel.org Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
2022-01-20hw/arm/virt: Use the PA range to compute the memory mapMarc Zyngier
The highmem attribute is nothing but another way to express the PA range of a VM. To support HW that has a smaller PA range then what QEMU assumes, pass this PA range to the virt_set_memmap() function, allowing it to correctly exclude highmem devices if they are outside of the PA range. Signed-off-by: Marc Zyngier <maz@kernel.org> Reviewed-by: Eric Auger <eric.auger@redhat.com> Message-id: 20220114140741.1358263-5-maz@kernel.org Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
2022-01-20hw/arm/virt: Honor highmem setting when computing the memory mapMarc Zyngier
Even when the VM is configured with highmem=off, the highest_gpa field includes devices that are above the 4GiB limit. Similarily, nothing seem to check that the memory is within the limit set by the highmem=off option. This leads to failures in virt_kvm_type() on systems that have a crippled IPA range, as the reported IPA space is larger than what it should be. Instead, honor the user-specified limit to only use the devices at the lowest end of the spectrum, and fail if we have memory crossing the 4GiB limit. Reviewed-by: Andrew Jones <drjones@redhat.com> Reviewed-by: Eric Auger <eric.auger@redhat.com> Signed-off-by: Marc Zyngier <maz@kernel.org> Message-id: 20220114140741.1358263-4-maz@kernel.org Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
2022-01-20hw/arm/virt: Add a control for the the highmem redistributorsMarc Zyngier
Just like we can control the enablement of the highmem PCIe region using highmem_ecam, let's add a control for the highmem GICv3 redistributor region. Similarily to highmem_ecam, these redistributors are disabled when highmem is off. Reviewed-by: Andrew Jones <drjones@redhat.com> Signed-off-by: Marc Zyngier <maz@kernel.org> Reviewed-by: Eric Auger <eric.auger@redhat.com> Message-id: 20220114140741.1358263-3-maz@kernel.org Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
2022-01-20hw/arm/virt: Add a control for the the highmem PCIe MMIOMarc Zyngier
Just like we can control the enablement of the highmem PCIe ECAM region using highmem_ecam, let's add a control for the highmem PCIe MMIO region. Similarily to highmem_ecam, this region is disabled when highmem is off. Signed-off-by: Marc Zyngier <maz@kernel.org> Reviewed-by: Eric Auger <eric.auger@redhat.com> Message-id: 20220114140741.1358263-2-maz@kernel.org Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
2022-01-20hw/arm/virt: Support for virtio-mem-pciGavin Shan
This supports virtio-mem-pci device on "virt" platform, by simply following the implementation on x86. * This implements the hotplug handlers to support virtio-mem-pci device hot-add, while the hot-remove isn't supported as we have on x86. * The block size is 512MB on ARM64 instead of 128MB on x86. * It has been passing the tests with various combinations like 64KB and 4KB page sizes on host and guest, different memory device backends like normal, transparent huge page and HugeTLB, plus migration. Co-developed-by: David Hildenbrand <david@redhat.com> Co-developed-by: Jonathan Cameron <Jonathan.Cameron@huawei.com> Signed-off-by: Gavin Shan <gshan@redhat.com> Reviewed-by: Jonathan Cameron <Jonathan.Cameron@Huawei.com> Reviewed-by: David Hildenbrand <david@redhat.com> Message-id: 20220111063329.74447-3-gshan@redhat.com Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
2022-01-20hw/arm/virt: Support cluster level in DT cpu-mapYanan Wang
Support one cluster level between core and physical package in the cpu-map of Arm/virt devicetree. This is also consistent with Linux Doc "Documentation/devicetree/bindings/cpu/cpu-topology.txt". Signed-off-by: Yanan Wang <wangyanan55@huawei.com> Reviewed-by: Andrew Jones <drjones@redhat.com> Message-id: 20220107083232.16256-3-wangyanan55@huawei.com Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
2022-01-20hw/arm/virt: Support CPU cluster on ARM virt machineYanan Wang
ARM64 machines like Kunpeng Family Server Chips have a level of hardware topology in which a group of CPU cores share L3 cache tag or L2 cache. For example, Kunpeng 920 typically has 6 or 8 clusters in each NUMA node (also represent range of CPU die), and each cluster has 4 CPU cores. All clusters share L3 cache data, but CPU cores in each cluster share a local L3 tag. Running a guest kernel with Cluster-Aware Scheduling on the Hosts which have physical clusters, if we can design a vCPU topology with cluster level for guest kernel and then have a dedicated vCPU pinning, the guest will gain scheduling performance improvement from cache affinity of CPU cluster. So let's enable the support for this new parameter on ARM virt machines. After this patch, we can define a 4-level CPU hierarchy like: cpus=*,maxcpus=*,sockets=*,clusters=*, cores=*,threads=*. Signed-off-by: Yanan Wang <wangyanan55@huawei.com> Reviewed-by: Andrew Jones <drjones@redhat.com> Message-id: 20220107083232.16256-2-wangyanan55@huawei.com Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
2022-01-18hw/arm: add control knob to disable kaslr_seed via DTBAlex Bennée
Generally a guest needs an external source of randomness to properly enable things like address space randomisation. However in a trusted boot environment where the firmware will cryptographically verify components having random data in the DTB will cause verification to fail. Add a control knob so we can prevent this being added to the system DTB. Signed-off-by: Alex Bennée <alex.bennee@linaro.org> Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Acked-by: Ilias Apalodimas <ilias.apalodimas@linaro.org> Acked-by: Jerome Forissier <jerome@forissier.org> Reviewed-by: Andrew Jones <drjones@redhat.com> Message-Id: <20220105135009.1584676-22-alex.bennee@linaro.org>
2022-01-07smbios: Rename SMBIOS_ENTRY_POINT_* enumsEduardo Habkost
Rename the enums to match the naming style used by QAPI, and to use "32" and "64" instead of "20" and "31". This will allow us to more easily move the enum to the QAPI schema later. About the naming choice: "SMBIOS 2.1 entry point"/"SMBIOS 3.0 entry point" and "32-bit entry point"/"64-bit entry point" are synonymous in the SMBIOS specification. However, the phrases "32-bit entry point" and "64-bit entry point" are used more often. The new names also avoid confusion between the entry point format and the actual SMBIOS version reported in the entry point structure. For example: currently the 32-bit entry point actually report SMBIOS 2.8 support, not 2.1. Based on portions of a patch submitted by Daniel P. Berrangé. Signed-off-by: Eduardo Habkost <ehabkost@redhat.com> Message-Id: <20211026151100.1691925-2-ehabkost@redhat.com> Reviewed-by: Philippe Mathieu-Daudé <philmd@redhat.com> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
2022-01-05hw: Add compat machines for 7.0Cornelia Huck
Add 7.0 machine types for arm/i440fx/q35/s390x/spapr. Signed-off-by: Cornelia Huck <cohuck@redhat.com> Reviewed-by: Juan Quintela <quintela@redhat.com> Reviewed-by: Andrew Jones <drjones@redhat.com> Reviewed-by: Daniel P. Berrangé <berrange@redhat.com> Reviewed-by: Christian Borntraeger <borntraeger@de.ibm.com> Acked-by: Cédric Le Goater <clg@kaod.org> Message-Id: <20211217143948.289995-1-cohuck@redhat.com> Signed-off-by: Thomas Huth <thuth@redhat.com>
2021-12-15hw/arm/virt: Use object_property_set instead of qdev_prop_setJean-Philippe Brucker
To propagate errors to the caller of the pre_plug callback, use the object_poperty_set*() functions directly instead of the qdev_prop_set*() helpers. Suggested-by: Igor Mammedov <imammedo@redhat.com> Reviewed-by: Eric Auger <eric.auger@redhat.com> Reviewed-by: Igor Mammedov <imammedo@redhat.com> Signed-off-by: Jean-Philippe Brucker <jean-philippe@linaro.org> Message-id: 20211210170415.583179-5-jean-philippe@linaro.org Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
2021-12-15hw/arm/virt: Reject instantiation of multiple IOMMUsJean-Philippe Brucker
We do not support instantiating multiple IOMMUs. Before adding a virtio-iommu, check that no other IOMMU is present. This will detect both "iommu=smmuv3" machine parameter and another virtio-iommu instance. Fixes: 70e89132c9 ("hw/arm/virt: Add the virtio-iommu device tree mappings") Reviewed-by: Eric Auger <eric.auger@redhat.com> Reviewed-by: Igor Mammedov <imammedo@redhat.com> Signed-off-by: Jean-Philippe Brucker <jean-philippe@linaro.org> Message-id: 20211210170415.583179-4-jean-philippe@linaro.org Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
2021-12-15hw/arm/virt: Remove device tree restriction for virtio-iommuJean-Philippe Brucker
virtio-iommu is now supported with ACPI VIOT as well as device tree. Remove the restriction that prevents from instantiating a virtio-iommu device under ACPI. Acked-by: Igor Mammedov <imammedo@redhat.com> Reviewed-by: Eric Auger <eric.auger@redhat.com> Signed-off-by: Jean-Philippe Brucker <jean-philippe@linaro.org> Message-id: 20211210170415.583179-3-jean-philippe@linaro.org Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
2021-12-15hw/arm: Don't include qemu-common.h unnecessarilyPeter Maydell
A lot of C files in hw/arm include qemu-common.h when they don't need anything from it. Drop the include lines. omap1.c, pxa2xx.c and strongarm.c retain the include because they use it for the prototype of qemu_get_timedate(). Signed-off-by: Peter Maydell <peter.maydell@linaro.org> Reviewed-by: Richard Henderson <richard.henderson@linaro.org> Reviewed-by: Philippe Mathieu-Daudé <f4bug@amsat.org> Reviewed-by: Taylor Simpson <tsimpson@quicinc.com> Reviewed-by: Yoshinori Sato <ysato@users.sourceforge.jp> Message-id: 20211129200510.1233037-5-peter.maydell@linaro.org
2021-11-26hw/arm/virt: Extend nested and mte checks to hvfAlexander Graf
The virt machine has properties to enable MTE and Nested Virtualization support. However, its check to ensure the backing accel implementation supports it today only looks for KVM and bails out if it finds it. Extend the checks to HVF as well as it does not support either today. This will cause QEMU to print a useful error message rather than silently ignoring the attempt by the user to enable either MTE or the Virtualization extensions. Reported-by: saar amar <saaramar5@gmail.com> Signed-off-by: Alexander Graf <agraf@csgraf.de> Message-id: 20211123122859.22452-1-agraf@csgraf.de Reviewed-by: Peter Maydell <peter.maydell@linaro.org> Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
2021-11-02hw/arm/virt: Rename default_bus_bypass_iommuJean-Philippe Brucker
Since commit d8fb7d0969d5 ("vl: switch -M parsing to keyval"), machine parameter definitions cannot use underscores, because keyval_dashify() transforms them to dashes and the parser doesn't find the parameter. This affects option default_bus_bypass_iommu which was introduced in the same release: $ qemu-system-aarch64 -M virt,default_bus_bypass_iommu=on qemu-system-aarch64: Property 'virt-6.1-machine.default-bus-bypass-iommu' not found Rename the parameter to "default-bus-bypass-iommu". Passing "default_bus_bypass_iommu" is still valid since the underscore are transformed automatically. Fixes: 6d7a85483a06 ("hw/arm/virt: Add default_bus_bypass_iommu machine option") Signed-off-by: Jean-Philippe Brucker <jean-philippe@linaro.org> Tested-by: Eric Auger <eric.auger@redhat.com> Reviewed-by: Eric Auger <eric.auger@redhat.com> Reviewed-by: Philippe Mathieu-Daudé <philmd@redhat.com> Message-Id: <20211026093733.2144161-1-jean-philippe@linaro.org> Signed-off-by: Richard Henderson <richard.henderson@linaro.org>
2021-10-20hw/arm/virt: Add cpu-map to device treeAndrew Jones
Support device tree CPU topology descriptions. In accordance with the Devicetree Specification, the Linux Doc "arm/cpus.yaml" requires that cpus and cpu nodes in the DT are present. And we have already met the requirement by generating /cpus/cpu@* nodes for members within ms->smp.cpus. Accordingly, we should also create subnodes in cpu-map for the present cpus, each of which relates to an unique cpu node. The Linux Doc "cpu/cpu-topology.txt" states that the hierarchy of CPUs in a SMP system is defined through four entities and they are socket/cluster/core/thread. It is also required that a socket node's child nodes must be one or more cluster nodes. Given that currently we are only provided with information of socket/core/thread, we assume there is one cluster child node in each socket node when creating cpu-map. Co-developed-by: Yanan Wang <wangyanan55@huawei.com> Signed-off-by: Andrew Jones <drjones@redhat.com> Signed-off-by: Yanan Wang <wangyanan55@huawei.com> Message-Id: <20211020142125.7516-4-wangyanan55@huawei.com> Signed-off-by: Richard Henderson <richard.henderson@linaro.org>
2021-10-20hw/arm/virt: Only describe cpu topology since virt-6.2Yanan Wang
On existing older machine types, without cpu topology described in ACPI or DT, the guest will populate one by default. With the topology described, it will read the information and set up its topology as instructed, but that may not be the same as what was getting used by default. It's possible that an user application has a dependency on the default topology and if the default one gets changed it will probably behave differently. Based on above consideration we'd better only describe topology information to the guest on 6.2 and later machine types. Signed-off-by: Yanan Wang <wangyanan55@huawei.com> Reviewed-by: Andrew Jones <drjones@redhat.com> Message-Id: <20211020142125.7516-2-wangyanan55@huawei.com> Signed-off-by: Richard Henderson <richard.henderson@linaro.org>
2021-10-15qdev: Make DeviceState.id independent of QemuOptsKevin Wolf
DeviceState.id is a pointer to a string that is stored in the QemuOpts object DeviceState.opts and freed together with it. We want to create devices without going through QemuOpts in the future, so make this a separately allocated string. Signed-off-by: Kevin Wolf <kwolf@redhat.com> Reviewed-by: Vladimir Sementsov-Ogievskiy <vsementsov@virtuozzo.com> Message-Id: <20211008133442.141332-9-kwolf@redhat.com> Reviewed-by: Damien Hedde <damien.hedde@greensocs.com> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Tested-by: Peter Krempa <pkrempa@redhat.com> Signed-off-by: Kevin Wolf <kwolf@redhat.com>
2021-10-01machine: Move smp_prefer_sockets to struct SMPCompatPropsYanan Wang
Now we have a common structure SMPCompatProps used to store information about SMP compatibility stuff, so we can also move smp_prefer_sockets there for cleaner code. No functional change intended. Signed-off-by: Yanan Wang <wangyanan55@huawei.com> Acked-by: David Gibson <david@gibson.dropbear.id.au> Reviewed-by: Andrew Jones <drjones@redhat.com> Reviewed-by: Daniel P. Berrangé <berrange@redhat.com> Message-Id: <20210929025816.21076-15-wangyanan55@huawei.com> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2021-10-01machine: Prefer cores over sockets in smp parsing since 6.2Yanan Wang
In the real SMP hardware topology world, it's much more likely that we have high cores-per-socket counts and few sockets totally. While the current preference of sockets over cores in smp parsing results in a virtual cpu topology with low cores-per-sockets counts and a large number of sockets, which is just contrary to the real world. Given that it is better to make the virtual cpu topology be more reflective of the real world and also for the sake of compatibility, we start to prefer cores over sockets over threads in smp parsing since machine type 6.2 for different arches. In this patch, a boolean "smp_prefer_sockets" is added, and we only enable the old preference on older machines and enable the new one since type 6.2 for all arches by using the machine compat mechanism. Suggested-by: Daniel P. Berrange <berrange@redhat.com> Signed-off-by: Yanan Wang <wangyanan55@huawei.com> Acked-by: David Gibson <david@gibson.dropbear.id.au> Acked-by: Cornelia Huck <cohuck@redhat.com> Reviewed-by: Andrew Jones <drjones@redhat.com> Reviewed-by: Pankaj Gupta <pankaj.gupta@ionos.com> Reviewed-by: Daniel P. Berrangé <berrange@redhat.com> Message-Id: <20210929025816.21076-10-wangyanan55@huawei.com> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2021-09-13hw/arm/virt: add ITS support in virt GICShashi Mallela
Included creation of ITS as part of virt platform GIC initialization. This Emulated ITS model now co-exists with kvm ITS and is enabled in absence of kvm irq kernel support in a platform. Signed-off-by: Shashi Mallela <shashi.mallela@linaro.org> Reviewed-by: Peter Maydell <peter.maydell@linaro.org> Message-id: 20210910143951.92242-9-shashi.mallela@linaro.org Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
2021-09-01hw/arm/virt: target-arm: Add A64FX processor support to virt machineShuuichirou Ishii
Add -cpu a64fx to use A64FX processor when -machine virt option is specified. In addition, add a64fx to the Supported guest CPU types in the virt.rst document. Signed-off-by: Shuuichirou Ishii <ishii.shuuichir@fujitsu.com> Reviewed-by: Andrew Jones <drjones@redhat.com> Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
2021-09-01hw: Add compat machines for 6.2Yanan Wang
Add 6.2 machine types for arm/i440fx/q35/s390x/spapr. Signed-off-by: Yanan Wang <wangyanan55@huawei.com> Acked-by: David Gibson <david@gibson.dropbear.id.au> Reviewed-by: Andrew Jones <drjones@redhat.com> Reviewed-by: Cornelia Huck <cohuck@redhat.com> Reviewed-by: Pankaj Gupta <pankaj.gupta@ionos.com> Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
2021-08-26hw/arm/virt: Delete EL3 error checksnow provided in CPU realizePeter Maydell
Now that the CPU realize function will fail cleanly if we ask for EL3 when KVM is enabled, we don't need to check for errors explicitly in the virt board code. The reported message is slightly different; it is now: qemu-system-aarch64: Cannot enable KVM when guest CPU has EL3 enabled instead of: qemu-system-aarch64: mach-virt: KVM does not support Security extensions We don't delete the MTE check because there the logic is more complex; deleting the check would work but makes the error message less helpful, as it would read: qemu-system-aarch64: MTE requested, but not supported by the guest CPU instead of: qemu-system-aarch64: mach-virt: KVM does not support providing MTE to the guest CPU Signed-off-by: Peter Maydell <peter.maydell@linaro.org> Reviewed-by: Richard Henderson <richard.henderson@linaro.org> Reviewed-by: Philippe Mathieu-Daudé <f4bug@amsat.org> Message-id: 20210816135842.25302-4-peter.maydell@linaro.org
2021-07-16hw/arm/virt: Add default_bus_bypass_iommu machine optionXingang Wang
Add a default_bus_bypass_iommu machine option to enable/disable bypass_iommu for default root bus. The option is disabled by default and can be enabled with: $QEMU -machine virt,iommu=smmuv3,default_bus_bypass_iommu=true Signed-off-by: Xingang Wang <wangxingang5@huawei.com> Message-Id: <1625748919-52456-4-git-send-email-wangxingang5@huawei.com> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
2021-07-09hw/arm/virt: Make PL061 GPIO lines pulled low, not highPeter Maydell
For the virt board we have two PL061 devices -- one for NonSecure which is inputs only, and one for Secure which is outputs only. For the former, we don't care whether its outputs are pulled low or high when the line is configured as an input, because we don't connect them. For the latter, we do care, because we wire the lines up to the gpio-pwr device, which assumes that level 1 means "do the action" and 1 means "do nothing". For consistency in case we add more outputs in future, configure both PL061s to pull GPIO lines down to 0. Reported-by: Maxim Uvarov <maxim.uvarov@linaro.org> Signed-off-by: Peter Maydell <peter.maydell@linaro.org> Reviewed-by: Richard Henderson <richard.henderson@linaro.org>
2021-06-16Merge remote-tracking branch ↵Peter Maydell
'remotes/pmaydell/tags/pull-target-arm-20210616' into staging target-arm queue: * hw/intc/arm_gicv3_cpuif: Tolerate spurious EOIR writes * handle some UNALLOCATED decode cases correctly rather than asserting * hw: virt: consider hw_compat_6_0 * hw/arm: add quanta-gbs-bmc machine * hw/intc/armv7m_nvic: Remove stale comment * target/arm: Fix mte page crossing test * hw/arm: quanta-q71l add pca954x muxes * target/arm: First few parts of MVE support # gpg: Signature made Wed 16 Jun 2021 14:34:49 BST # gpg: using RSA key E1A5C593CD419DE28E8315CF3C2525ED14360CDE # gpg: issuer "peter.maydell@linaro.org" # gpg: Good signature from "Peter Maydell <peter.maydell@linaro.org>" [ultimate] # gpg: aka "Peter Maydell <pmaydell@gmail.com>" [ultimate] # gpg: aka "Peter Maydell <pmaydell@chiark.greenend.org.uk>" [ultimate] # Primary key fingerprint: E1A5 C593 CD41 9DE2 8E83 15CF 3C25 25ED 1436 0CDE * remotes/pmaydell/tags/pull-target-arm-20210616: (25 commits) include/qemu/int128.h: Add function to create Int128 from int64_t bitops.h: Provide hswap32(), hswap64(), wswap64() swapping operations target/arm: Move expand_pred_b() data to vec_helper.c target/arm: Add framework for MVE decode target/arm: Implement MVE LETP insn target/arm: Implement MVE DLSTP target/arm: Implement MVE WLSTP insn target/arm: Implement MVE LCTP target/arm: Let vfp_access_check() handle late NOCP checks target/arm: Add handling for PSR.ECI/ICI target/arm: Handle VPR semantics in existing code target/arm: Enable FPSCR.QC bit for MVE target/arm: Provide and use H8 and H1_8 macros hw/arm: quanta-q71l add pca954x muxes hw/arm: gsj add pca9548 hw/arm: gsj add i2c comments target/arm: Fix mte page crossing test hw/intc/armv7m_nvic: Remove stale comment hw/arm: quanta-gbs-bmc add i2c comments hw/arm: add quanta-gbs-bmc machine ... Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
2021-06-15hw: virt: consider hw_compat_6_0Heinrich Schuchardt
virt-6.0 must consider hw_compat_6_0. Fixes: da7e13c00b59 ("hw: add compat machines for 6.1") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Cornelia Huck <cohuck@redhat.com> Message-id: 20210610183500.54207-1-xypron.glpk@gmx.de Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
2021-06-15arm: Eliminate all TPM related code if CONFIG_TPM is not setStefan Berger
Peter Maydell <peter.maydell@linaro.org> Signed-off-by: Stefan Berger <stefanb@linux.ibm.com> Reviewed-by: Philippe Mathieu-Daudé <philmd@redhat.com> Tested-by: Philippe Mathieu-Daudé <philmd@redhat.com> Message-Id: <20210614191335.1968807-3-stefanb@linux.ibm.com> Signed-off-by: Philippe Mathieu-Daudé <philmd@redhat.com>
2021-05-16Merge remote-tracking branch 'remotes/mst/tags/for_upstream' into stagingPeter Maydell
pc,pci,virtio: bugfixes, improvements Fixes all over the place. Faster boot for virtio. ioeventfd support for mmio. Signed-off-by: Michael S. Tsirkin <mst@redhat.com> # gpg: Signature made Fri 14 May 2021 15:27:13 BST # gpg: using RSA key 5D09FD0871C8F85B94CA8A0D281F0DB8D28D5469 # gpg: issuer "mst@redhat.com" # gpg: Good signature from "Michael S. Tsirkin <mst@kernel.org>" [full] # gpg: aka "Michael S. Tsirkin <mst@redhat.com>" [full] # 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 * remotes/mst/tags/for_upstream: Fix build with 64 bits time_t vhost-vdpa: Make vhost_vdpa_get_device_id() static hw/virtio: enable ioeventfd configuring for mmio hw/smbios: support for type 41 (onboard devices extended information) checkpatch: Fix use of uninitialized value virtio-scsi: Configure all host notifiers in a single MR transaction virtio-scsi: Set host notifiers and callbacks separately virtio-blk: Configure all host notifiers in a single MR transaction virtio-blk: Fix rollback path in virtio_blk_data_plane_start() pc-dimm: remove unnecessary get_vmstate_memory_region() method amd_iommu: fix wrong MMIO operations virtio-net: Constify VirtIOFeature feature_sizes[] virtio-blk: Constify VirtIOFeature feature_sizes[] hw/virtio: Pass virtio_feature_get_config_size() a const argument x86: acpi: use offset instead of pointer when using build_header() amd_iommu: Fix pte_override_page_mask() Signed-off-by: Peter Maydell <peter.maydell@linaro.org> # Conflicts: # hw/arm/virt.c
2021-05-14hw/smbios: support for type 41 (onboard devices extended information)Vincent Bernat
Type 41 defines the attributes of devices that are onboard. The original intent was to imply the BIOS had some level of control over the enablement of the associated devices. If network devices are present in this table, by default, udev will name the corresponding interfaces enoX, X being the instance number. Without such information, udev will fallback to using the PCI ID and this usually gives ens3 or ens4. This can be a bit annoying as the name of the network card may depend on the order of options and may change if a new PCI device is added earlier on the commande line. Being able to provide SMBIOS type 41 entry ensure the name of the interface won't change and helps the user guess the right name without booting a first time. This can be invoked with: $QEMU -netdev user,id=internet -device virtio-net-pci,mac=50:54:00:00:00:42,netdev=internet,id=internet-dev \ -smbios type=41,designation='Onboard LAN',instance=1,kind=ethernet,pcidev=internet-dev The PCI segment is assumed to be 0. This should hold true for most cases. $ dmidecode -t 41 # dmidecode 3.3 Getting SMBIOS data from sysfs. SMBIOS 2.8 present. Handle 0x2900, DMI type 41, 11 bytes Onboard Device Reference Designation: Onboard LAN Type: Ethernet Status: Enabled Type Instance: 1 Bus Address: 0000:00:09.0 $ ip -brief a lo UNKNOWN 127.0.0.1/8 ::1/128 eno1 UP 10.0.2.14/24 fec0::5254:ff:fe00:42/64 fe80::5254:ff:fe00:42/64 Signed-off-by: Vincent Bernat <vincent@bernat.ch> Message-Id: <20210401171138.62970-1-vincent@bernat.ch> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
generated by cgit v1.2.3 (git 2.26.2) at 2025-02-09 11:33:43 +0000