aboutsummaryrefslogtreecommitdiff
path: root/hw/arm
AgeCommit message (Collapse)AuthorFilesLines
2022-03-02target/arm: Report KVM's actual PSCI version to guest in dtbPeter Maydell1-3/+2
When we're using KVM, the PSCI implementation is provided by the kernel, but QEMU has to tell the guest about it via the device tree. Currently we look at the KVM_CAP_ARM_PSCI_0_2 capability to determine if the kernel is providing at least PSCI 0.2, but if the kernel provides a newer version than that we will still only tell the guest it has PSCI 0.2. (This is fairly harmless; it just means the guest won't use newer parts of the PSCI API.) The kernel exposes the specific PSCI version it is implementing via the ONE_REG API; use this to report in the dtb that the PSCI implementation is 1.0-compatible if appropriate. (The device tree binding currently only distinguishes "pre-0.2", "0.2-compatible" and "1.0-compatible".) Signed-off-by: Peter Maydell <peter.maydell@linaro.org> Reviewed-by: Marc Zyngier <maz@kernel.org> Reviewed-by: Akihiko Odaki <akihiko.odaki@gmail.com> Reviewed-by: Richard Henderson <richard.henderson@linaro.org> Reviewed-by: Andrew Jones <drjones@redhat.com> Message-id: 20220224134655.1207865-1-peter.maydell@linaro.org
2022-03-02target/arm: Support PSCI 1.1 and SMCCC 1.0Akihiko Odaki1-3/+9
Support the latest PSCI on TCG and HVF. A 64-bit function called from AArch32 now returns NOT_SUPPORTED, which is necessary to adhere to SMC Calling Convention 1.0. It is still not compliant with SMCCC 1.3 since they do not implement mandatory functions. Signed-off-by: Akihiko Odaki <akihiko.odaki@gmail.com> Message-id: 20220213035753.34577-1-akihiko.odaki@gmail.com Reviewed-by: Peter Maydell <peter.maydell@linaro.org> [PMM: update MISMATCH_CHECK checks on PSCI_VERSION macros to match] Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
2022-03-02hw/arm/mps2-tz.c: Update AN547 documentation URLPeter Maydell1-1/+1
The AN547 application note URL has changed: update our comment accordingly. (Rev B is still downloadable from the old URL, but there is a new Rev C of the document now.) Signed-off-by: Peter Maydell <peter.maydell@linaro.org> Reviewed-by: Philippe Mathieu-Daudé <f4bug@amsat.org> Tested-by: Philippe Mathieu-Daudé <f4bug@amsat.org> Message-id: 20220221094144.426191-1-peter.maydell@linaro.org
2022-03-02mps3-an547: Add missing user ahb interfacesJimmy Brisson1-0/+4
With these interfaces missing, TFM would delegate peripherals 0, 1, 2, 3 and 8, and qemu would ignore the delegation of interface 8, as it thought interface 4 was eth & USB. This patch corrects this behavior and allows TFM to delegate the eth & USB peripheral to NS mode. (The old QEMU behaviour was based on revision B of the AN547 appnote; revision C corrects this error in the documentation, and this commit brings QEMU in to line with how the FPGA image really behaves.) Signed-off-by: Jimmy Brisson <jimmy.brisson@linaro.org> Message-id: 20220210210227.3203883-1-jimmy.brisson@linaro.org Reviewed-by: Peter Maydell <peter.maydell@linaro.org> [PMM: added commit message note clarifying that the old behaviour was a docs issue, not because there were two different versions of the FPGA image] Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
2022-02-28Merge remote-tracking branch 'remotes/legoater/tags/pull-aspeed-20220227' ↵Peter Maydell2-71/+36
into staging aspeed queue: * Removal of the swift-bmc machine * New Secure Boot Controller model * Improvements on the rainier machine * Various small cleanups # gpg: Signature made Sun 27 Feb 2022 08:45:45 GMT # gpg: using RSA key A0F66548F04895EBFE6B0B6051A343C7CFFBECA1 # gpg: Good signature from "Cédric Le Goater <clg@kaod.org>" [undefined] # gpg: WARNING: This key is not certified with a trusted signature! # gpg: There is no indication that the signature belongs to the owner. # Primary key fingerprint: A0F6 6548 F048 95EB FE6B 0B60 51A3 43C7 CFFB ECA1 * remotes/legoater/tags/pull-aspeed-20220227: aspeed/sdmc: Add trace events aspeed/smc: Add an address mask on segment registers aspeed: Introduce a create_pca9552() helper aspeed: rainier: Add strap values taken from hardware aspeed: rainier: Add i2c LED devices ast2600: Add Secure Boot Controller model arm: Remove swift-bmc machine Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
2022-02-26aspeed: Introduce a create_pca9552() helperCédric Le Goater1-22/+27
This unifies the way we create the pca9552 devices on the different boards. Suggested-by: Philippe Mathieu-Daudé <f4bug@amsat.org> Reviewed-by: Philippe Mathieu-Daudé <f4bug@amsat.org> Signed-off-by: Cédric Le Goater <clg@kaod.org>
2022-02-26aspeed: rainier: Add strap values taken from hardwareJoel Stanley1-2/+2
When time permits, we should introduce defines for the HW strapping registers to cleanly decode the values. SCU500 = 0x00422016 Disable ARM JTAG trusted world debug: 0x1 Disable ARM JTAG debug: 0x1 VGA Memory Size: 0x1 [16MB] Cortex M3: 0x1 [Disabled] Boot device: 0x1 [eMMC] Reserved: 0x1 SCU510 = 0x80000848 Secure Boot Enable: 0x1 Enable boot SPI or eMMC ABR (second boot): 0x1 Enable LPC mode: 0x1 [LPC] Disable LPC SuperIO 0x2e/0x4e: 0x1 Signed-off-by: Joel Stanley <joel@jms.id.au> [ clg: rewrote the commit log ] Signed-off-by: Cédric Le Goater <clg@kaod.org>
2022-02-26aspeed: rainier: Add i2c LED devicesJoel Stanley1-0/+15
This helps quieten booting the current Rainier kernel. Reviewed-by: Philippe Mathieu-Daudé <f4bug@amsat.org> Signed-off-by: Joel Stanley <joel@jms.id.au> Signed-off-by: Cédric Le Goater <clg@kaod.org>
2022-02-26ast2600: Add Secure Boot Controller modelJoel Stanley1-0/+9
Just a stub that indicates the system has booted in secure boot mode. Used for testing the driver: https://lore.kernel.org/all/20211019080608.283324-1-joel@jms.id.au/ Signed-off-by: Joel Stanley <joel@jms.id.au> [ clg: - Fixed typo - Adjusted Copyright dates ] Signed-off-by: Cédric Le Goater <clg@kaod.org>
2022-02-26arm: Remove swift-bmc machineJoel Stanley1-64/+0
It was scheduled for removal in 7.0. Signed-off-by: Joel Stanley <joel@jms.id.au> Reviewed-by: Cédric Le Goater <clg@kaod.org> Signed-off-by: Cédric Le Goater <clg@kaod.org>
2022-02-22Merge remote-tracking branch ↵Peter Maydell1-0/+1
'remotes/thuth-gitlab/tags/pull-request-2022-02-21' into staging * Improve virtio-net failover test * Some small fixes for the qtests * Misc header cleanups by Philippe # gpg: Signature made Mon 21 Feb 2022 11:40:37 GMT # gpg: using RSA key 27B88847EEE0250118F3EAB92ED9D774FE702DB5 # gpg: issuer "thuth@redhat.com" # gpg: Good signature from "Thomas Huth <th.huth@gmx.de>" [full] # gpg: aka "Thomas Huth <thuth@redhat.com>" [full] # gpg: aka "Thomas Huth <huth@tuxfamily.org>" [full] # gpg: aka "Thomas Huth <th.huth@posteo.de>" [unknown] # Primary key fingerprint: 27B8 8847 EEE0 2501 18F3 EAB9 2ED9 D774 FE70 2DB5 * remotes/thuth-gitlab/tags/pull-request-2022-02-21: (25 commits) hw/tricore: Remove unused and incorrect header hw/m68k/mcf: Add missing 'exec/hwaddr.h' header exec/exec-all: Move 'qemu/log.h' include in units requiring it softmmu/runstate: Clean headers linux-user: Add missing "qemu/timer.h" include target: Add missing "qemu/timer.h" include core/ptimers: Remove unnecessary 'sysemu/cpus.h' include exec/ramblock: Add missing includes qtest: Add missing 'hw/qdev-core.h' include hw/acpi/memory_hotplug: Remove unused 'hw/acpi/pc-hotplug.h' header hw/remote: Add missing include hw/tpm: Clean includes scripts: Remove the old switch-timer-api script tests/qtest: failover: migration abort test with failover off tests/qtest: failover: test migration if the guest doesn't support failover tests/qtest: failover: check migration with failover off tests/qtest: failover: check missing guest feature tests/qtest: failover: check the feature is correctly provided tests/qtest: failover: use a macro for check_one_card() tests/qtest: failover: clean up pathname of tests ... Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
2022-02-21hw/arm: add initial mori-bmc boardPatrick Venture1-0/+32
This is the BMC attached to the OpenBMC Mori board. Signed-off-by: Patrick Venture <venture@google.com> Reviewed-by: Chris Rauer <crauer@google.com> Reviewed-by: Ilkyun Choi <ikchoi@google.com> Message-id: 20220208233104.284425-1-venture@google.com Reviewed-by: Peter Maydell <peter.maydell@linaro.org> Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
2022-02-21include: Move hardware version declarations to new qemu/hw-version.hPeter Maydell1-0/+1
The "hardware version" machinery (qemu_set_hw_version(), qemu_hw_version(), and the QEMU_HW_VERSION define) is used by fewer than 10 files. Move it out from osdep.h into a new qemu/hw-version.h. Signed-off-by: Peter Maydell <peter.maydell@linaro.org> Reviewed-by: Philippe Mathieu-Daudé <f4bug@amsat.org> Reviewed-by: Richard Henderson <richard.henderson@linaro.org> Message-id: 20220208200856.3558249-6-peter.maydell@linaro.org
2022-02-21hw/arm/armv7m: Handle disconnected clock inputsPeter Maydell1-4/+22
In the armv7m object, handle clock inputs that aren't connected. This is always an error for 'cpuclk'. For 'refclk' it is OK for this to be disconnected, but we need to handle it by not trying to connect a sourceless-clock to the systick device. This fixes a bug where on the mps2-an521 and similar boards (which do not have a refclk) the systick device incorrectly reset with SYST_CSR.CLKSOURCE 0 ("use refclk") rather than 1 ("use CPU clock"). Cc: qemu-stable@nongnu.org Reported-by: Richard Petri <git@rpls.de> Signed-off-by: Peter Maydell <peter.maydell@linaro.org> Reviewed-by: Philippe Mathieu-Daudé <f4bug@amsat.org> Reviewed-by: Richard Henderson <richard.henderson@linaro.org> Message-id: 20220208171643.3486277-1-peter.maydell@linaro.org
2022-02-21Kconfig: Add 'imply I2C_DEVICES' on boards with available i2c busPeter Maydell1-0/+10
For arm boards with an i2c bus which a user could reasonably want to plug arbitrary devices, add 'imply I2C_DEVICES' to the Kconfig stanza. Signed-off-by: Peter Maydell <peter.maydell@linaro.org> Acked-by: Paolo Bonzini <pbonzini@redhat.com> Reviewed-by: Philippe Mathieu-Daudé <f4bug@amsat.org> Reviewed-by: Hao Wu <wuhaotsh@google.com> Message-id: 20220208155911.3408455-3-peter.maydell@linaro.org
2022-02-21exec/exec-all: Move 'qemu/log.h' include in units requiring itPhilippe Mathieu-Daudé1-0/+1
Many files use "qemu/log.h" declarations but neglect to include it (they inherit it via "exec/exec-all.h"). "exec/exec-all.h" is a core component and shouldn't be used that way. Move the "qemu/log.h" inclusion locally to each unit requiring it. Signed-off-by: Philippe Mathieu-Daudé <f4bug@amsat.org> Reviewed-by: Richard Henderson <richard.henderson@linaro.org> Acked-by: Thomas Huth <thuth@redhat.com> Message-Id: <20220207082756.82600-10-f4bug@amsat.org> Signed-off-by: Thomas Huth <thuth@redhat.com>
2022-02-08hw/arm/smmuv3: Fix device resetEric Auger1-0/+6
We currently miss a bunch of register resets in the device reset function. This sometimes prevents the guest from rebooting after a system_reset (with virtio-blk-pci). For instance, we may get the following errors: invalid STE smmuv3-iommu-memory-region-0-0 translation failed for iova=0x13a9d2000(SMMU_EVT_C_BAD_STE) Invalid read at addr 0x13A9D2000, size 2, region '(null)', reason: rejected invalid STE smmuv3-iommu-memory-region-0-0 translation failed for iova=0x13a9d2000(SMMU_EVT_C_BAD_STE) Invalid write at addr 0x13A9D2000, size 2, region '(null)', reason: rejected invalid STE Signed-off-by: Eric Auger <eric.auger@redhat.com> Message-id: 20220202111602.627429-1-eric.auger@redhat.com Fixes: 10a83cb988 ("hw/arm/smmuv3: Skeleton") Reviewed-by: Peter Maydell <peter.maydell@linaro.org> Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
2022-02-08hw/arm: versal-virt: Always call arm_load_kernel()Edgar E. Iglesias1-9/+2
Always call arm_load_kernel() regardless of kernel_filename being set. This is needed because arm_load_kernel() sets up reset for the CPUs. Fixes: 6f16da53ff (hw/arm: versal: Add a virtual Xilinx Versal board) Reported-by: Peter Maydell <peter.maydell@linaro.org> Signed-off-by: Edgar E. Iglesias <edgar.iglesias@xilinx.com> Message-id: 20220130110313.4045351-2-edgar.iglesias@gmail.com Reviewed-by: Peter Maydell <peter.maydell@linaro.org> Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
2022-02-08hw/arm/boot: Drop existing dtb /psci node rather than retaining itPeter Maydell1-3/+4
If we're using PSCI emulation, we add a /psci node to the device tree we pass to the guest. At the moment, if the dtb already has a /psci node in it, we retain it, rather than replacing it. (This behaviour was added in commit c39770cd637765 in 2018.) This is a problem if the existing node doesn't match our PSCI emulation. In particular, it might specify the wrong method (HVC vs SMC), or wrong function IDs for cpu_suspend/cpu_off/etc, in which case the guest will not get the behaviour it wants when it makes PSCI calls. An example of this is trying to boot the highbank or midway board models using the device tree supplied in the kernel sources: this device tree includes a /psci node that specifies function IDs that don't match the (PSCI 0.2 compliant) IDs that QEMU uses. The dtb cpu_suspend function ID happens to match the PSCI 0.2 cpu_off ID, so the guest hangs after booting when the kernel tries to idle the CPU and instead it gets turned off. Instead of retaining an existing /psci node, delete it entirely and replace it with a node whose properties match QEMU's PSCI emulation behaviour. This matches the way we handle /memory nodes, where we also delete any existing nodes and write in ones that match the way QEMU is going to behave. 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: Edgar E. Iglesias <edgar.iglesias@xilinx.com> Tested-by: Cédric Le Goater <clg@kaod.org> Tested-by: Niek Linnenbank <nieklinnenbank@gmail.com> Message-id: 20220127154639.2090164-17-peter.maydell@linaro.org
2022-02-08hw/arm/boot: Drop nb_cpus field from arm_boot_infoPeter Maydell17-25/+5
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/highbank: Drop unused secondary boot stub codePeter Maydell1-56/+0
The highbank and midway board code includes boot-stub code for handling secondary CPU boot which keeps the secondaries in a pen until the primary writes to a known location with the address they should jump to. This code is never used, because the boards enable QEMU's PSCI emulation, so secondary CPUs are kept powered off until the PSCI call which turns them on, and then start execution from the address given by the guest in that PSCI call. Delete the unreachable code. (The code was wrong for midway in any case -- on the Cortex-A15 the GIC CPU interface registers are at a different offset from PERIPHBASE compared to the Cortex-A9, and the code baked-in the offsets for highbank's A9.) Note that this commit implicitly depends on the preceding "Don't write secondary boot stub if using PSCI" commit -- the default secondary-boot stub code overlaps with one of the highbank-specific bootcode rom blobs, so we must suppress the secondary-boot stub code entirely, not merely replace the highbank-specific version with the default. 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-15-peter.maydell@linaro.org
2022-02-08hw/arm/boot: Don't write secondary boot stub if using PSCIPeter Maydell1-11/+24
If we're using PSCI emulation to start secondary CPUs, there is no point in writing the "secondary boot" stub code, because it will never be used -- secondary CPUs start powered-off, and when powered on are set to begin execution at the address specified by the guest's power-on PSCI call, not at the stub. Move the call to the hook that writes the secondary boot stub code so that we can do it only if we're starting a Linux kernel and not using PSCI. (None of the users of the hook care about the ordering of its call relative to anything else: they only use it to write a rom blob to guest memory.) 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-14-peter.maydell@linaro.org
2022-02-08hw/arm/boot: Prevent setting both psci_conduit and secure_board_setupPeter Maydell1-0/+10
Now that we have dealt with the one special case (highbank) that needed to set both psci_conduit and secure_board_setup, we don't need to allow that combination any more. It doesn't make sense in general, so use an assertion to ensure we don't add new boards that do it by accident without thinking through the consequences. 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-13-peter.maydell@linaro.org
2022-02-08hw/arm/highbank: Drop use of secure_board_setupPeter Maydell1-8/+0
Guest code on highbank may make non-PSCI SMC calls in order to enable/disable the L2x0 cache controller (see the Linux kernel's arch/arm/mach-highbank/highbank.c highbank_l2c310_write_sec() function). The ABI for this is documented in kernel commit 8e56130dcb as being borrowed from the OMAP44xx ROM. The OMAP44xx TRM documents this function ID as having no return value and potentially trashing all guest registers except SP and PC. For QEMU's purposes (where our L2x0 model is a stub and enabling or disabling it doesn't affect the guest behaviour) a simple "do nothing" SMC is fine. We currently implement this NOP behaviour using a little bit of Secure code we run before jumping to the guest kernel, which is written by arm_write_secure_board_setup_dummy_smc(). The code sets up a set of Secure vectors where the SMC entry point returns without doing anything. Now that the PSCI SMC emulation handles all SMC calls (setting r0 to an error code if the input r0 function identifier is not recognized), we can use that default behaviour as sufficient for the highbank cache controller call. (Because the guest code assumes r0 has no interesting value on exit it doesn't matter that we set it to the error code). We can therefore delete the highbank board code that sets secure_board_setup to true and writes the secure-code bootstub. (Note that because the OMAP44xx ABI puts function-identifiers in r12 and PSCI uses r0, we only avoid a clash because Linux's code happens to put the function-identifier in both registers. But this is true also when the kernel is running on real firmware that implements both ABIs as far as I can see.) This change fixes in passing booting on the 'midway' board model, which has been completely broken since we added support for Hyp mode to the Cortex-A15 CPU. When we did that boot.c was made to start running the guest code in Hyp mode; this includes the board_setup hook, which instantly UNDEFs because the NSACR is not accessible from Hyp. (Put another way, we never made the secure_board_setup hook support cope with Hyp mode.) 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-12-peter.maydell@linaro.org
2022-02-08hw/arm: highbank: For EL3 guests, don't enable PSCI, start all coresPeter Maydell1-6/+1
Change the highbank/midway boards to use the new boot.c functionality to allow us to enable psci-conduit only if the guest is being booted in EL1 or EL2, so that if the user runs guest EL3 firmware code our PSCI emulation doesn't get in its way. To do this we stop setting the psci-conduit and start-powered-off properties on the CPU objects in the board code, and instead set the psci_conduit field in the arm_boot_info struct to tell the common boot loader code that we'd like PSCI if the guest is starting at an EL that it makes sense with (in which case it will set these properties). This means that when running guest code at EL3, all the cores will start execution at once on poweron. This matches the real hardware behaviour. (A brief description of the hardware boot process is in the u-boot documentation for these boards: https://u-boot.readthedocs.io/en/latest/board/highbank/highbank.html#boot-process -- in theory one might run the 'a9boot'/'a15boot' secure monitor code in QEMU, though we probably don't emulate enough for that.) This affects the highbank and midway boards. 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-10-peter.maydell@linaro.org
2022-02-08hw/arm/virt: Let boot.c handle PSCI enablementPeter Maydell1-11/+1
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-02-08hw/arm/versal: Let boot.c handle PSCI enablementPeter Maydell2-6/+5
Instead of setting the CPU psci-conduit and start-powered-off properties in the xlnx-versal-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. (EL3 guest code started via -bios, -pflash, or the generic loader was already being run with PSCI emulation disabled.) Note that EL3 guest code has no way to turn on the secondary CPUs because there's no emulated power controller, but this was already true for EL3 guest code run via -bios, -pflash, or the generic loader. Signed-off-by: Peter Maydell <peter.maydell@linaro.org> Reviewed-by: Edgar E. Iglesias <edgar.iglesias@xilinx.com> Reviewed-by: Richard Henderson <richard.henderson@linaro.org> Reviewed-by: Niek Linnenbank <nieklinnenbank@gmail.com> Tested-by: Edgar E. Iglesias <edgar.iglesias@xilinx.com> Tested-by: Cédric Le Goater <clg@kaod.org> Tested-by: Niek Linnenbank <nieklinnenbank@gmail.com> Message-id: 20220127154639.2090164-8-peter.maydell@linaro.org
2022-02-08hw/arm/xlnx-zcu102: Don't enable PSCI conduit when booting guest in EL3Peter Maydell2-5/+7
Change the Xilinx ZynqMP-based board xlnx-zcu102 to use the new boot.c functionality to allow us to enable psci-conduit only if the guest is being booted in EL1 or EL2, so that if the user runs guest EL3 firmware code our PSCI emulation doesn't get in its way. To do this we stop setting the psci-conduit property on the CPU objects in the SoC code, and instead set the psci_conduit field in the arm_boot_info struct to tell the common boot loader code that we'd like PSCI if the guest is starting at an EL that it makes sense with. Note that this means that EL3 guest code will have no way to power on secondary cores, because we don't model any kind of power controller that does that on this SoC. Signed-off-by: Peter Maydell <peter.maydell@linaro.org> Reviewed-by: Edgar E. Iglesias <edgar.iglesias@xilinx.com> Reviewed-by: Richard Henderson <richard.henderson@linaro.org> Reviewed-by: Niek Linnenbank <nieklinnenbank@gmail.com> Tested-by: Edgar E. Iglesias <edgar.iglesias@xilinx.com> Tested-by: Cédric Le Goater <clg@kaod.org> Tested-by: Niek Linnenbank <nieklinnenbank@gmail.com> Acked-by: Richard Henderson <richard.henderson@linaro.org> Message-id: 20220127154639.2090164-7-peter.maydell@linaro.org
2022-02-08hw/arm: allwinner: Don't enable PSCI conduit when booting guest in EL3Peter Maydell2-5/+5
Change the allwinner-h3 based board to use the new boot.c functionality to allow us to enable psci-conduit only if the guest is being booted in EL1 or EL2, so that if the user runs guest EL3 firmware code our PSCI emulation doesn't get in its way. To do this we stop setting the psci-conduit property on the CPU objects in the SoC code, and instead set the psci_conduit field in the arm_boot_info struct to tell the common boot loader code that we'd like PSCI if the guest is starting at an EL that it makes sense with. This affects the orangepi-pc board. This commit leaves the secondary CPUs in the powered-down state if the guest is booting at EL3, which is the same behaviour as before this commit. The secondaries can no longer be started by that EL3 code making a PSCI call but can still be started via the CPU Configuration Module registers (which we model in hw/misc/allwinner-cpucfg.c). 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-6-peter.maydell@linaro.org
2022-02-08hw/arm: imx: Don't enable PSCI conduit when booting guest in EL3Peter Maydell4-6/+6
Change the iMX-SoC based boards to use the new boot.c functionality to allow us to enable psci-conduit only if the guest is being booted in EL1 or EL2, so that if the user runs guest EL3 firmware code our PSCI emulation doesn't get in its way. To do this we stop setting the psci-conduit property on the CPU objects in the SoC code, and instead set the psci_conduit field in the arm_boot_info struct to tell the common boot loader code that we'd like PSCI if the guest is starting at an EL that it makes sense with. This affects the mcimx6ul-evk and mcimx7d-sabre boards. Note that for the mcimx7d board, this means that when running guest code at EL3 there is currently no way to power on the secondary CPUs, because we do not currently have a model of the system reset controller module which should be used to do that for the imx7 SoC, only for the imx6 SoC. (Previously EL3 code which knew it was running on QEMU could use a PSCI call to do this.) This doesn't affect the imx6ul-evk board because it is uniprocessor. Signed-off-by: Peter Maydell <peter.maydell@linaro.org> Reviewed-by: Richard Henderson <richard.henderson@linaro.org> Tested-by: Edgar E. Iglesias <edgar.iglesias@xilinx.com> Tested-by: Cédric Le Goater <clg@kaod.org> Acked-by: Richard Henderson <richard.henderson@linaro.org> Message-id: 20220127154639.2090164-5-peter.maydell@linaro.org
2022-02-08hw/arm/boot: Support setting psci-conduit based on guest ELPeter Maydell1-0/+50
Currently we expect board code to set the psci-conduit property on CPUs and ensure that secondary CPUs are created with the start-powered-off property set to false, if the board wishes to use QEMU's builtin PSCI emulation. This worked OK for the virt board where we first wanted to use it, because the virt board directly creates its CPUs and is in a reasonable position to set those properties. For other boards which model real hardware and use a separate SoC object, however, it is more awkward. Most PSCI-using boards just set the psci-conduit board unconditionally. This was never strictly speaking correct (because you would not be able to run EL3 guest firmware that itself provided the PSCI interface, as the QEMU implementation would overrule it), but mostly worked in practice because for non-PSCI SMC calls QEMU would emulate the SMC instruction as normal (by trapping to guest EL3). However, we would like to make our PSCI emulation follow the part of the SMCC specification that mandates that SMC calls with unknown function identifiers return a failure code, which means that all SMC calls will be handled by the PSCI code and the "emulate as normal" path will no longer be taken. We tried to implement that in commit 9fcd15b9193e81 ("arm: tcg: Adhere to SMCCC 1.3 section 5.2"), but this regressed attempts to run EL3 guest code on the affected boards: * mcimx6ul-evk, mcimx7d-sabre, orangepi, xlnx-zcu102 * for the case only of EL3 code loaded via -kernel (and not via -bios or -pflash), virt and xlnx-versal-virt so for the 7.0 release we reverted it (in commit 4825eaae4fdd56f). This commit provides a mechanism that boards can use to arrange that psci-conduit is set if running guest code at a low enough EL but not if it would be running at the same EL that the conduit implies that the QEMU PSCI implementation is using. (Later commits will convert individual board models to use this mechanism.) We do this by moving the setting of the psci-conduit and start-powered-off properties to arm_load_kernel(). Boards which want to potentially use emulated PSCI must set a psci_conduit field in the arm_boot_info struct to the type of conduit they want to use (SMC or HVC); arm_load_kernel() will then set the CPUs up accordingly if it is not going to start the guest code at the same or higher EL as the fake QEMU firmware would be at. Board/SoC code which uses this mechanism should no longer set the CPU psci-conduit property directly. It should only set the start-powered-off property for secondaries if EL3 guest firmware running bare metal expects that rather than the alternative "all CPUs start executing the firmware at once". Note that when calculating whether we are going to run guest code at EL3, we ignore the setting of arm_boot_info::secure_board_setup, which might cause us to run a stub bit of guest code at EL3 which does some board-specific setup before dropping to EL2 or EL1 to run the guest kernel. This is OK because only one board that enables PSCI sets secure_board_setup (the highbank board), and the stub code it writes will behave the same way whether the one SMC call it makes is handled by "emulate the SMC" or by "PSCI default returns an error code". So we can leave that stub code in place until after we've changed the PSCI default behaviour; at that point we will remove it. Signed-off-by: Peter Maydell <peter.maydell@linaro.org> Reviewed-by: Richard Henderson <richard.henderson@linaro.org> Tested-by: Edgar E. Iglesias <edgar.iglesias@xilinx.com> Tested-by: Cédric Le Goater <clg@kaod.org> Message-id: 20220127154639.2090164-4-peter.maydell@linaro.org
2022-02-08hw/arm/xlnx-zynqmp: 'Or' the QSPI / QSPI DMA IRQsFrancisco Iglesias1-2/+12
'Or' the IRQs coming from the QSPI and QSPI DMA models. This is done for avoiding the situation where one of the models incorrectly deasserts an interrupt asserted from the other model (which will result in that the IRQ is lost and will not reach guest SW). Signed-off-by: Francisco Iglesias <francisco.iglesias@xilinx.com> Reviewed-by: Philippe Mathieu-Daudé <f4bug@amsat.org> Reviewed-by: Luc Michel <luc@lmichel.fr> Message-id: 20220203151742.1457-1-francisco.iglesias@xilinx.com Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
2022-01-28hw/arm: ast2600: Fix address mapping of second SPI controllerCédric Le Goater1-1/+1
Address should be 0x1E631000 and not 0x1E641000 as initially introduced. Resolves: https://gitlab.com/qemu-project/qemu/-/issues/838 Fixes: f25c0ae1079d ("aspeed/soc: Add AST2600 support") Suggested-by: Troy Lee <troy_lee@aspeedtech.com> Signed-off-by: Cédric Le Goater <clg@kaod.org> Reviewed-by: Philippe Mathieu-Daudé <f4bug@amsat.org> Message-id: 20220126083520.4135713-1-clg@kaod.org Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
2022-01-28hw/arm/xlnx-versal-virt: Connect mt35xu01g flashes to the OSPIFrancisco Iglesias1-0/+23
Connect Micron Xccela mt35xu01g flashes to the OSPI flash memory controller. Signed-off-by: Francisco Iglesias <francisco.iglesias@xilinx.com> Reviewed-by: Edgar E. Iglesias <edgar.iglesias@xilinx.com> Reviewed-by: Peter Maydell <peter.maydell@linaro.org> Message-id: 20220121161141.14389-10-francisco.iglesias@xilinx.com Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
2022-01-28hw/arm/xlnx-versal: Connect the OSPI flash memory controller modelFrancisco Iglesias1-0/+93
Connect the OSPI flash memory controller model (including the source and destination DMA). Signed-off-by: Francisco Iglesias <francisco.iglesias@xilinx.com> Reviewed-by: Peter Maydell <peter.maydell@linaro.org> Message-id: 20220121161141.14389-8-francisco.iglesias@xilinx.com Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
2022-01-28hw/arm/xlnx-versal: Connect Versal's PMC SLCRFrancisco Iglesias1-1/+70
Connect Versal's PMC SLCR (system-level control registers) model. Signed-off-by: Francisco Iglesias <francisco.iglesias@xilinx.com> Reviewed-by: Luc Michel <luc@lmichel.fr> Message-id: 20220121161141.14389-4-francisco.iglesias@xilinx.com Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
2022-01-28hw/arm/xlnx-versal: 'Or' the interrupts from the BBRAM and RTC modelsFrancisco Iglesias2-3/+27
Add an orgate and 'or' the interrupts from the BBRAM and RTC models. Signed-off-by: Francisco Iglesias <francisco.iglesias@xilinx.com> Reviewed-by: Peter Maydell <peter.maydell@linaro.org> Reviewed-by: Luc Michel <luc@lmichel.fr> Message-id: 20220121161141.14389-3-francisco.iglesias@xilinx.com Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
2022-01-28rtc: Move RTC function prototypes to their own headerPeter Maydell3-3/+3
softmmu/rtc.c defines two public functions: qemu_get_timedate() and qemu_timedate_diff(). Currently we keep the prototypes for these in qemu-common.h, but most files don't need them. Move them to their own header, a new include/sysemu/rtc.h. Since the C files using these two functions did not need to include qemu-common.h for any other reason, we can remove those include lines when we add the include of the new rtc.h. The license for the .h file follows that of the softmmu/rtc.c where both the functions are defined. Signed-off-by: Peter Maydell <peter.maydell@linaro.org> Reviewed-by: Philippe Mathieu-Daudé <f4bug@amsat.org>
2022-01-28hw/armv7m: Fix broken VMStateDescriptionPeter Maydell1-2/+2
In commit d5093d961585f02 we added a VMStateDescription to the TYPE_ARMV7M object, to handle migration of its Clocks. However a cut-and-paste error meant we used the wrong struct name in the VMSTATE_CLOCK() macro arguments. The result was that attempting a 'savevm' might result in an assertion failure. Cc: qemu-stable@nongnu.org Buglink: https://gitlab.com/qemu-project/qemu/-/issues/803 Fixes: d5093d961585f02 Signed-off-by: Peter Maydell <peter.maydell@linaro.org> Reviewed-by: Ani Sinha <ani@anisinha.ca> Reviewed-by: Alex Bennée <alex.bennee@linaro.org> Reviewed-by: Philippe Mathieu-Daudé <f4bug@amsat.org> Message-id: 20220120151609.433555-1-peter.maydell@linaro.org
2022-01-20hw/arm/aspeed: Add the i3c device to the AST2600 SoCTroy Lee1-0/+16
Add the new i3c device to the AST2600 SoC. Signed-off-by: Troy Lee <troy_lee@aspeedtech.com> Reviewed-by: Graeme Gregory <quic_ggregory@quicinc.com> Reviewed-by: Cédric Le Goater <clg@kaod.org> Tested-by: Graeme Gregory <quic_ggregory@quicinc.com> Message-id: 20220111084546.4145785-3-troy_lee@aspeedtech.com [PMM: tidied commit message] Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
2022-01-20hw/arm: kudo add lm75s behind bus 1 switch at 75Patrick Venture1-1/+9
Reviewed-by: Hao Wu <wuhaotsh@google.com> Signed-off-by: Patrick Venture <venture@google.com> Message-id: 20220111172338.1525587-1-venture@google.com Reviewed-by: Peter Maydell <peter.maydell@linaro.org> Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
2022-01-20hw/arm/virt: Drop superfluous checks against highmemMarc Zyngier2-6/+1
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 Zyngier1-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>
2022-01-20hw/arm/virt: Use the PA range to compute the memory mapMarc Zyngier1-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>
2022-01-20hw/arm/virt: Honor highmem setting when computing the memory mapMarc Zyngier1-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>
2022-01-20hw/arm/virt: Add a control for the the highmem redistributorsMarc Zyngier2-0/+4
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 Zyngier2-8/+9
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 Shan2-0/+71
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 Wang1-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>
2022-01-20hw/arm/virt: Support CPU cluster on ARM virt machineYanan Wang1-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>
generated by cgit v1.1 at 2024-12-27 06:04:45 +0000