aboutsummaryrefslogtreecommitdiff
path: root/hw/arm
AgeCommit message (Collapse)AuthorFilesLines
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>
2022-01-20hw/net: Move MV88W8618 network device out of hw/arm/ directoryPhilippe Mathieu-Daudé1-380/+1
The Marvell 88W8618 network device is hidden in the Musicpal machine. Move it into a new unit file under the hw/net/ directory. Acked-by: Richard Henderson <richard.henderson@linaro.org> Signed-off-by: Philippe Mathieu-Daudé <f4bug@amsat.org> Message-id: 20220107184429.423572-4-f4bug@amsat.org Reviewed-by: Peter Maydell <peter.maydell@linaro.org> Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
2022-01-20hw/arm/musicpal: Fix coding style of code related to MV88W8618 devicePhilippe Mathieu-Daudé1-7/+7
We are going to move this code, so fix its style first to avoid: ERROR: spaces required around that '/' (ctx:VxV) Reviewed-by: Richard Henderson <richard.henderson@linaro.org> Signed-off-by: Philippe Mathieu-Daudé <f4bug@amsat.org> Message-id: 20220107184429.423572-3-f4bug@amsat.org Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
2022-01-20hw: Move MARVELL_88W8618 Kconfig from audio/ to arm/Philippe Mathieu-Daudé1-0/+3
The Marvell 88W8618 is a system-on-chip with an ARM core. We implement its audio codecs and network interface. Homogeneous SoC Kconfig are usually defined in the hw/$ARCH directory. Move it there. Suggested-by: Richard Henderson <richard.henderson@linaro.org> Reviewed-by: Richard Henderson <richard.henderson@linaro.org> Signed-off-by: Philippe Mathieu-Daudé <f4bug@amsat.org> Message-id: 20220107184429.423572-2-f4bug@amsat.org Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
2022-01-18hw/arm: add control knob to disable kaslr_seed via DTBAlex Bennée1-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>
2022-01-07Merge tag 'for_upstream' of git://git.kernel.org/pub/scm/virt/kvm/mst/qemu ↵Richard Henderson2-1/+2
into staging virtio,pci,pc: features,fixes,cleanups New virtio mem options. A vhost-user cleanup. Control over smbios entry point type. Config interrupt support for vdpa. Fixes, cleanups all over the place. Signed-off-by: Michael S. Tsirkin <mst@redhat.com> # gpg: Signature made Fri 07 Jan 2022 04:30:41 PM PST # gpg: using RSA key 5D09FD0871C8F85B94CA8A0D281F0DB8D28D5469 # gpg: issuer "mst@redhat.com" # gpg: Good signature from "Michael S. Tsirkin <mst@kernel.org>" [undefined] # gpg: aka "Michael S. Tsirkin <mst@redhat.com>" [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: 0270 606B 6F3C DF3D 0B17 0970 C350 3912 AFBE 8E67 # Subkey fingerprint: 5D09 FD08 71C8 F85B 94CA 8A0D 281F 0DB8 D28D 5469 * tag 'for_upstream' of git://git.kernel.org/pub/scm/virt/kvm/mst/qemu: (55 commits) tests: acpi: Add updated TPM related tables acpi: tpm: Add missing device identification objects tests: acpi: prepare for updated TPM related tables virtio/vhost-vsock: don't double close vhostfd, remove redundant cleanup hw/scsi/vhost-scsi: don't double close vhostfd on error hw/scsi/vhost-scsi: don't leak vqs on error docs: reSTify virtio-balloon-stats documentation and move to docs/interop hw/i386/pc: Add missing property descriptions acpihp: simplify acpi_pcihp_disable_root_bus tests: acpi: SLIC: update expected blobs tests: acpi: add SLIC table test tests: acpi: whitelist expected blobs before changing them acpi: fix QEMU crash when started with SLIC table intel-iommu: correctly check passthrough during translation virtio-mem: Set "unplugged-inaccessible=auto" for the 7.0 machine on x86 virtio-mem: Support VIRTIO_MEM_F_UNPLUGGED_INACCESSIBLE linux-headers: sync VIRTIO_MEM_F_UNPLUGGED_INACCESSIBLE MAINTAINERS: Add a separate entry for acpi/VIOT tables virtio: signal after wrapping packed used_idx virtio-mem: Support "prealloc=on" option ... Signed-off-by: Richard Henderson <richard.henderson@linaro.org>
2022-01-07acpi: tpm: Add missing device identification objectsStefan Berger1-0/+1
Add missing TPM device identification objects _STR and _UID. They will appear as files 'description' and 'uid' under Linux sysfs. Following inspection of sysfs entries for hardware TPMs we chose uid '1'. Cc: Shannon Zhao <shannon.zhaosl@gmail.com> Cc: Michael S. Tsirkin <mst@redhat.com> Cc: Igor Mammedov <imammedo@redhat.com> Cc: Ani Sinha <ani@anisinha.ca> Resolves: https://gitlab.com/qemu-project/qemu/-/issues/708 Signed-off-by: Stefan Berger <stefanb@linux.ibm.com> Reviewed-by: Ani Sinha <ani@anisinha.ca> Reviewed-by: Shannon Zhao <shannon.zhaosl@gmail.com> Message-id: 20211223022310.575496-3-stefanb@linux.ibm.com Message-Id: <20220104175806.872996-3-stefanb@linux.ibm.com> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com> Reviewed-by: Igor Mammedov <imammedo@redhat.com>
2022-01-07hw/arm: kudo add lm75s on bus 13Patrick Venture1-1/+10
Add the four lm75s behind the mux on bus 13. Tested by booting the firmware: lm75 42-0048: hwmon0: sensor 'lm75' lm75 43-0049: supply vs not found, using dummy regulator lm75 43-0049: hwmon1: sensor 'lm75' lm75 44-0048: supply vs not found, using dummy regulator lm75 44-0048: hwmon2: sensor 'lm75' lm75 45-0049: supply vs not found, using dummy regulator lm75 45-0049: hwmon3: sensor 'lm75' Signed-off-by: Patrick Venture <venture@google.com> Reviewed-by: Titus Rwantare <titusr@google.com> Reviewed-by: Philippe Mathieu-Daudé <f4bug@amsat.org> Message-id: 20220102215844.2888833-5-venture@google.com Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
2022-01-07hw/arm: add i2c muxes to kudo-bmcPatrick Venture1-0/+9
Signed-off-by: Patrick Venture <venture@google.com> Reviewed-by: Hao Wu <wuhaotsh@google.com> Reviewed-by: Philippe Mathieu-Daudé <f4bug@amsat.org> Message-id: 20220102215844.2888833-4-venture@google.com Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
2022-01-07hw/arm: attach MMC to kudo-bmcShengtan Mao1-0/+1
Signed-off-by: Shengtan Mao <stmao@google.com> Reviewed-by: Hao Wu <wuhaotsh@google.com> Reviewed-by: Chris Rauer <crauer@google.com> Message-id: 20220102215844.2888833-3-venture@google.com Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
2022-01-07hw/arm: Add kudo i2c eeproms.Chris Rauer1-0/+8
Signed-off-by: Chris Rauer <crauer@google.com> Reviewed-by: Hao Wu <wuhaotsh@google.com> Reviewed-by: Patrick Venture <venture@google.com> Reviewed-by: Philippe Mathieu-Daudé <f4bug@amsat.org> Message-id: 20220102215844.2888833-2-venture@google.com Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
2022-01-07Add dummy Aspeed AST2600 Display Port MCU (DPMCU)Troy Lee1-0/+8
AST2600 Display Port MCU introduces 0x18000000~0x1803FFFF as it's memory and io address. If guest machine try to access DPMCU memory, it will cause a fatal error. Signed-off-by: Troy Lee <troy_lee@aspeedtech.com> Reviewed-by: Philippe Mathieu-Daudé <f4bug@amsat.org> Reviewed-by: Cédric Le Goater <clg@kaod.org> Message-id: 20211210083034.726610-1-troy_lee@aspeedtech.com Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
2022-01-07smbios: Rename SMBIOS_ENTRY_POINT_* enumsEduardo Habkost1-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>
2022-01-05hw: Add compat machines for 7.0Cornelia Huck1-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>
2021-12-30dma: Let dma_memory_read/write() take MemTxAttrs argumentPhilippe Mathieu-Daudé3-12/+18
Let devices specify transaction attributes when calling dma_memory_read() or dma_memory_write(). Patch created mechanically using spatch with this script: @@ expression E1, E2, E3, E4; @@ ( - dma_memory_read(E1, E2, E3, E4) + dma_memory_read(E1, E2, E3, E4, MEMTXATTRS_UNSPECIFIED) | - dma_memory_write(E1, E2, E3, E4) + dma_memory_write(E1, E2, E3, E4, MEMTXATTRS_UNSPECIFIED) ) Reviewed-by: Richard Henderson <richard.henderson@linaro.org> Reviewed-by: Li Qiang <liq3ea@gmail.com> Reviewed-by: Edgar E. Iglesias <edgar.iglesias@xilinx.com> Signed-off-by: Philippe Mathieu-Daudé <philmd@redhat.com> Acked-by: Stefan Hajnoczi <stefanha@redhat.com> Message-Id: <20211223115554.3155328-6-philmd@redhat.com>
2021-12-15Merge tag 'pull-block-2021-12-15' of git://repo.or.cz/qemu/armbru into stagingRichard Henderson18-38/+59
Block device patches patches for 2021-12-15 # gpg: Signature made Wed 15 Dec 2021 05:58:14 AM PST # gpg: using RSA key 354BC8B3D7EB2A6B68674E5F3870B400EB918653 # gpg: issuer "armbru@redhat.com" # gpg: Good signature from "Markus Armbruster <armbru@redhat.com>" [full] # gpg: aka "Markus Armbruster <armbru@pond.sub.org>" [full] * tag 'pull-block-2021-12-15' of git://repo.or.cz/qemu/armbru: blockdev: Drop unused drive_get_next() hw/arm/aspeed: Replace drive_get_next() by drive_get() hw/arm/xilinx_zynq: Replace drive_get_next() by drive_get() hw/arm/xlnx-zcu102: Replace drive_get_next() by drive_get() hw/microblaze: Replace drive_get_next() by drive_get() hw/arm/xlnx-versal-virt: Replace drive_get_next() by drive_get() hw/arm/mcimx7d-sabre: Replace drive_get_next() by drive_get() hw/arm/mcimx6ul-evk: Replace drive_get_next() by drive_get() hw/arm/imx25_pdk: Replace drive_get_next() by drive_get() hw/arm/versatilepb hw/arm/vexpress: Replace drive_get_next() by drive_get() hw/arm/npcm7xx_boards: Replace drive_get_next() by drive_get() hw: Replace trivial drive_get_next() by drive_get() hw/sd/ssi-sd: Do not create SD card within controller's realize Signed-off-by: Richard Henderson <richard.henderson@linaro.org>
2021-12-15hw/arm/aspeed: Replace drive_get_next() by drive_get()Markus Armbruster1-8/+13
drive_get_next() is basically a bad idea. It returns the "next" block backend of a certain interface type. "Next" means bus=0,unit=N, where subsequent calls count N up from zero, per interface type. This lets you define unit numbers implicitly by execution order. If the order changes, or new calls appear "in the middle", unit numbers change. ABI break. Hard to spot in review. The aspeed machines connects backends with drive_get_next() in several counting loops, one of them in a helper function, and a conditional. Change it to use drive_get() directly. This makes the unit numbers explicit in the code. Cc: "Cédric Le Goater" <clg@kaod.org> Cc: Peter Maydell <peter.maydell@linaro.org> Cc: Andrew Jeffery <andrew@aj.id.au> Cc: Joel Stanley <joel@jms.id.au> Cc: qemu-arm@nongnu.org Signed-off-by: Markus Armbruster <armbru@redhat.com> Message-Id: <20211117163409.3587705-13-armbru@redhat.com> Reviewed-by: Cédric Le Goater <clg@kaod.org>
generated by cgit v1.1 at 2025-01-15 12:57:10 +0000