summaryrefslogtreecommitdiffstats
path: root/hw/arm/virt.c
Commit message (Collapse)AuthorAgeFilesLines
* hw/arm/virt: Fix devicetree warnings about the virtio-iommu nodeJean-Philippe Brucker2022-10-271-2/+3
| | | | | | | | | | | | | | | | | | | | | | | | | The "PCI Bus Binding to: IEEE Std 1275-1994" defines the compatible string for a PCIe bus or endpoint as "pci<vendorid>,<deviceid>" or similar. Since the initial binding for PCI virtio-iommu didn't follow this rule, it was modified to accept both strings and ensure backward compatibility. Also, the unit-name for the node should be "device,function". Fix corresponding dt-validate and dtc warnings: pcie@10000000: virtio_iommu@16:compatible: ['virtio,pci-iommu'] does not contain items matching the given schema pcie@10000000: Unevaluated properties are not allowed (... 'virtio_iommu@16' were unexpected) From schema: linux/Documentation/devicetree/bindings/pci/host-generic-pci.yaml virtio_iommu@16: compatible: 'oneOf' conditional failed, one must be fixed: ['virtio,pci-iommu'] is too short 'pci1af4,1057' was expected From schema: dtschema/schemas/pci/pci-bus.yaml Warning (pci_device_reg): /pcie@10000000/virtio_iommu@16: PCI unit address format error, expected "2,0" Signed-off-by: Jean-Philippe Brucker <jean-philippe@linaro.org> Reviewed-by: Peter Maydell <peter.maydell@linaro.org> Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
* hw/arm/virt: Fix devicetree warning about the SMMU nodeJean-Philippe Brucker2022-09-291-2/+0Star
| | | | | | | | | | | | | | | The SMMUv3 node isn't expected to have clock properties (unlike the SMMUv2). Fix the corresponding dt-validate warning: smmuv3@9050000: 'clock-names', 'clocks' do not match any of the regexes: 'pinctrl-[0-9]+' From schema: linux/Documentation/devicetree/bindings/iommu/arm,smmu-v3.yaml Signed-off-by: Jean-Philippe Brucker <jean-philippe@linaro.org> Reviewed-by: Peter Maydell <peter.maydell@linaro.org> [PMM: tweaked commit message as suggested by Eric] Reviewed-by: Eric Auger <eric.auger@redhat.com> Message-id: 20220927100347.176606-7-jean-philippe@linaro.org Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
* hw/arm/virt: Use "msi-map" devicetree property for PCIJean-Philippe Brucker2022-09-291-2/+2
| | | | | | | | | | | | | | | | | | | | | The "msi-parent" property can be used on the PCI node when MSIs do not contain sideband data (device IDs) [1]. In QEMU, MSI transactions contain the requester ID, so the PCI node should use the "msi-map" property instead of "msi-parent". In our case the property describes an identity map between requester ID and sideband data. This fixes a warning when passing the DTB generated by QEMU to dtc, following a recent change to the GICv3 node: Warning (msi_parent_property): /pcie@10000000:msi-parent: property size (4) too small for cell size 1 [1] linux/Documentation/devicetree/bindings/pci/pci-msi.txt Signed-off-by: Jean-Philippe Brucker <jean-philippe@linaro.org> Reviewed-by: Peter Maydell <peter.maydell@linaro.org> Reviewed-by: Eric Auger <eric.auger@redhat.com> Message-id: 20220927100347.176606-4-jean-philippe@linaro.org Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
* hw/arm/virt: Fix devicetree warning about the GIC nodeJean-Philippe Brucker2022-09-291-0/+1
| | | | | | | | | | | | | | The GICv3 bindings requires a #msi-cells property for the ITS node. Fix the corresponding dt-validate warning: interrupt-controller@8000000: msi-controller@8080000: '#msi-cells' is a required property From schema: linux/Documentation/devicetree/bindings/interrupt-controller/arm,gic-v3.yaml Signed-off-by: Jean-Philippe Brucker <jean-philippe@linaro.org> Reviewed-by: Peter Maydell <peter.maydell@linaro.org> Reviewed-by: Eric Auger <eric.auger@redhat.com> Message-id: 20220927100347.176606-3-jean-philippe@linaro.org Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
* hw/arm/virt: Fix devicetree warning about the root nodeJean-Philippe Brucker2022-09-291-0/+1
| | | | | | | | | | | | | | | | | | | | The devicetree specification requires a 'model' property in the root node. Fix the corresponding dt-validate warning: /: 'model' is a required property From schema: dtschema/schemas/root-node.yaml Use the same name for model as for compatible. The specification recommends that 'compatible' follows the format 'manufacturer,model' and 'model' follows the format 'manufacturer,model-number'. Since our 'compatible' doesn't observe this, 'model' doesn't really need to either. Signed-off-by: Jean-Philippe Brucker <jean-philippe@linaro.org> Reviewed-by: Peter Maydell <peter.maydell@linaro.org> Reviewed-by: Eric Auger <eric.auger@redhat.com> Message-id: 20220927100347.176606-2-jean-philippe@linaro.org Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
* target/arm: Add cortex-a35Hao Wu2022-09-141-0/+1
| | | | | | | | | | Add cortex A35 core and enable it for virt board. Signed-off-by: Hao Wu <wuhaotsh@google.com> Reviewed-by: Joe Komlodi <komlodi@google.com> Reviewed-by: Peter Maydell <peter.maydell@linaro.org> Message-Id: <20220819002015.1663247-1-wuhaotsh@google.com> Signed-off-by: Richard Henderson <richard.henderson@linaro.org>
* hw: Add compat machines for 7.2Cornelia Huck2022-08-251-1/+8
| | | | | | | | | | | Add 7.2 machine types for arm/i440fx/m68k/q35/s390x/spapr. Signed-off-by: Cornelia Huck <cohuck@redhat.com> Reviewed-by: Daniel Henrique Barboza <danielhb413@gmail.com> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Message-Id: <20220727121755.395894-1-cohuck@redhat.com> [thuth: fixed conflict with pcmc->legacy_no_rng_seed] Signed-off-by: Thomas Huth <thuth@redhat.com>
* hw/arm/virt: dt: add rng-seed propertyJason A. Donenfeld2022-07-071-17/+27
| | | | | | | | | | | | | | | | In 60592cfed2 ("hw/arm/virt: dt: add kaslr-seed property"), the kaslr-seed property was added, but the equally as important rng-seed property was forgotten about, which has identical semantics for a similar purpose. This commit implements it in exactly the same way as kaslr-seed. It then changes the name of the disabling option to reflect that this has more to do with randomness vs determinism, rather than something particular about kaslr. Cc: Peter Maydell <peter.maydell@linaro.org> Signed-off-by: Jason A. Donenfeld <Jason@zx2c4.com> [PMM: added deprecated.rst section for the deprecation] Reviewed-by: Peter Maydell <peter.maydell@linaro.org> Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
* target/arm: Extend arm_pamax to more than aarch64Richard Henderson2022-06-271-9/+1Star
| | | | | | | | | | | Move the code from hw/arm/virt.c that is supposed to handle v7 into the one function. Signed-off-by: Richard Henderson <richard.henderson@linaro.org> Reported-by: He Zhe <zhe.he@windriver.com> Message-id: 20220619001541.131672-2-richard.henderson@linaro.org Reviewed-by: Peter Maydell <peter.maydell@linaro.org> Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
* hw/arm/virt: Drop #size-cells and #address-cells from gpio-keys dtb nodePeter Maydell2022-05-191-2/+0Star
| | | | | | | | | | | | | | | 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
* hw/arm/virt: Fix incorrect non-secure flash dtb node namePeter Maydell2022-05-191-1/+1
| | | | | | | | | | | | | | | | | 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
* hw/arm/virt: Fix CPU's default NUMA node IDGavin Shan2022-05-091-1/+3
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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>
* hw/arm/virt: Consider SMP configuration in CPU topologyGavin Shan2022-05-091-1/+14
| | | | | | | | | | | | | | | | | | | 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>
* target/arm: Define neoverse-n1Richard Henderson2022-05-091-0/+1
| | | | | | | | | 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>
* target/arm: Define cortex-a76Richard Henderson2022-05-091-0/+1
| | | | | | | | | 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>
* hw/core: Move the ARM sysbus-fdt to coreAlistair Francis2022-04-291-1/+1
| | | | | | | | | | | | | | 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>
* hw/arm/virt: Support TCG GICv4Peter Maydell2022-04-221-17/+53
| | | | | | | | | | | | | | | | | 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
* hw/arm/virt: Abstract out calculation of redistributor region capacityPeter Maydell2022-04-221-7/+4Star
| | | | | | | | | | | | | 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
* hw/arm/virt: Use VIRT_GIC_VERSION_* enum values in create_gic()Peter Maydell2022-04-221-8/+23
| | | | | | | | | | | | | | | | 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
* hw/arm/virt: Check for attempt to use TrustZone with KVM or HVFPeter Maydell2022-04-211-0/+7
| | | | | | | | | | | | | | | | | | | | | | | | 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
* hw: Add compat machines for 7.1Cornelia Huck2022-04-201-1/+8
| | | | | | | | | | | | | 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>
* hw/arm/virt: Fix gic-version=max when CONFIG_ARM_GICV3_TCG is unsetEric Auger2022-03-181-1/+6
| | | | | | | | | | | | | 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>
* hw/arm/virt: Disable LPA2 for -machine virt-6.2Richard Henderson2022-03-071-0/+7
| | | | | | | | | | | 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>
* hw/arm/boot: Drop nb_cpus field from arm_boot_infoPeter Maydell2022-02-081-1/+0Star
| | | | | | | | | | | | | | | 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
* hw/arm/virt: Let boot.c handle PSCI enablementPeter Maydell2022-02-081-11/+1Star
| | | | | | | | | | | | | | | | | | | 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
* hw/arm/virt: Drop superfluous checks against highmemMarc Zyngier2022-01-201-4/+1Star
| | | | | | | | | | | | 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>
* hw/arm/virt: Disable highmem devices that don't fit in the PA rangeMarc Zyngier2022-01-201-6/+28
| | | | | | | | | | | 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>
* hw/arm/virt: Use the PA range to compute the memory mapMarc Zyngier2022-01-201-12/+52
| | | | | | | | | | | | | 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>
* hw/arm/virt: Honor highmem setting when computing the memory mapMarc Zyngier2022-01-201-3/+7
| | | | | | | | | | | | | | | | | | | | | 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>
* hw/arm/virt: Add a control for the the highmem redistributorsMarc Zyngier2022-01-201-0/+2
| | | | | | | | | | | | | | | 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>
* hw/arm/virt: Add a control for the the highmem PCIe MMIOMarc Zyngier2022-01-201-2/+5
| | | | | | | | | | | | | | 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>
* hw/arm/virt: Support for virtio-mem-pciGavin Shan2022-01-201-0/+70
| | | | | | | | | | | | | | | | | | | | | | | | 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>
* hw/arm/virt: Support cluster level in DT cpu-mapYanan Wang2022-01-201-7/+8
| | | | | | | | | | | 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>
* hw/arm/virt: Support CPU cluster on ARM virt machineYanan Wang2022-01-201-0/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | 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>
* hw/arm: add control knob to disable kaslr_seed via DTBAlex Bennée2022-01-181-2/+30
| | | | | | | | | | | | | | | | 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>
* smbios: Rename SMBIOS_ENTRY_POINT_* enumsEduardo Habkost2022-01-071-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | 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>
* hw: Add compat machines for 7.0Cornelia Huck2022-01-051-1/+8
| | | | | | | | | | | | | 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>
* hw/arm/virt: Use object_property_set instead of qdev_prop_setJean-Philippe Brucker2021-12-151-2/+3
| | | | | | | | | | | | | 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>
* hw/arm/virt: Reject instantiation of multiple IOMMUsJean-Philippe Brucker2021-12-151-0/+5
| | | | | | | | | | | | | 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>
* hw/arm/virt: Remove device tree restriction for virtio-iommuJean-Philippe Brucker2021-12-151-8/+2Star
| | | | | | | | | | | | 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>
* hw/arm: Don't include qemu-common.h unnecessarilyPeter Maydell2021-12-151-1/+0Star
| | | | | | | | | | | | | | | 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
* hw/arm/virt: Extend nested and mte checks to hvfAlexander Graf2021-11-261-6/+9
| | | | | | | | | | | | | | | | | 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>
* hw/arm/virt: Rename default_bus_bypass_iommuJean-Philippe Brucker2021-11-021-2/+2
| | | | | | | | | | | | | | | | | | | | | | | | 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>
* hw/arm/virt: Add cpu-map to device treeAndrew Jones2021-10-211-10/+60
| | | | | | | | | | | | | | | | | | | | | | | | | 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>
* hw/arm/virt: Only describe cpu topology since virt-6.2Yanan Wang2021-10-211-0/+1
| | | | | | | | | | | | | | | | | | 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>
* qdev: Make DeviceState.id independent of QemuOptsKevin Wolf2021-10-151-1/+1
| | | | | | | | | | | | | | | 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>
* machine: Move smp_prefer_sockets to struct SMPCompatPropsYanan Wang2021-10-011-1/+1
| | | | | | | | | | | | | | | 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>
* machine: Prefer cores over sockets in smp parsing since 6.2Yanan Wang2021-10-011-0/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | 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>
* hw/arm/virt: add ITS support in virt GICShashi Mallela2021-09-131-2/+27
| | | | | | | | | | | | 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>
* hw/arm/virt: target-arm: Add A64FX processor support to virt machineShuuichirou Ishii2021-09-011-0/+1
| | | | | | | | | | 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>