I did not found direct evidence whether the CPU is in secure or non-secure mode in the Linux kernel boot log. By setting the variable to sec, U-Boot makes sure to boot it in secure mode (hence not installing the provided secure monitor). U-Boot allows to use the environment variable bootm_boot_mode to choose which mode the operating system should get started. Currently, U-Boot supports the PSCI interface v0.1, but there are already patches to support interface v1.0. The PSCI configuration option causes U-Boot to add a node device tree specifying the location of the PSCI firmware implementation. SMP: Total of 2 processors activated (96.00 BogoMIPS).
Psci: Using PSCI v0.1 Function IDs from DT Psci: probing for conduit method from DT. The boot log shows that PSCI is available. Therefore U-Boot already installs a secure monitor and switches the CPU into non-secure SVC mode (the configurations CONFIG_ARMV7_PSCI and CONFIG_ARMV7_NONSEC were already in use). The upstream configuration of U-Boot for i.MX 7 uses the PSCI interface to allow Linux to start secondary CPUs. The interface has to be implemented by a firmware running in secure mode. In that context the ARM PSCI (Power State Coordination Interface) should be mentioned too. ARM privilege levels & Linux/KVM and U-Boot PSCI ARM also provides a reference implementation called ARM trusted firmware that includes PSCI and also a number of other features. Thanks to the work of Andre Przywara, Marc Zyngier and others, the boot loader U-Boot has all the infrastructure to setup a secure monitor and switch the CPU into HYP mode, essentially providing such a firmware….
However, it would be an abuse of the architecture, it would violate separation of concerns. The architecture envisions a firmware running on the secure side to do that job, initialized early in boot flow e.g. Technically, I see no reason why the kernel couldn’t employ such an implementation. The reason is that the Linux kernel just does not provide the necessary infrastructure/code to switch the CPU into non-secure mode and ultimately enable the hypervisor mode. This confused me initially, as the secure SVC mode is a superior mode to any non-secure mode. But even when booting Linux in secure SVC mode, the kernel is not able to switch to the hypervisor mode by itself. Notable here is that on ARMv7 CPU’s the HYP mode is only available in non-secure mode, by design. Any hypervisor needs to operate in non-secure mode, there is no virtualization extension in secure mode.Īn ARMv7 CPU boots in the highest privilege mode, in the secure SVC mode.
U BOOT LINUX HOW TO
To understand how to switch into Hypervisor mode, one needs to understand the whole privilege level architecture first. Secure and Non-Secure world ARMv7 privilege levels After building a kernel with KVM support, I encountered this problem first: By default, the system did boot in SVC mode. How KVM uses the HYP mode in detail is explained in this excellent LWN article. The CPU needs to be in HYP mode when Linux is booting so KVM can make use of the extension. Linux with KVM for ARM uses this mode to provide CPU virtualization. The ARMv7 architecture with virtualization extension calls this privilege level PL2 or HYP mode. A similar separation between Kernel and hypervisor is required. User-space (PL0) uses the SVC (Supervisor) instruction to switch to kernel-space (PL1, SVC mode).
U BOOT LINUX FULL
To provide hardware support for full CPU virtualization an additional privilege level is required.
U BOOT LINUX SOFTWARE
I was not really familiar with the ARMv7 virtualization architecture, so I had to read up on some concepts. This post summarizes what I learned and gives a big picture of software support. I went ahead and tried to bring up KVM on i.MX 7. The NXP i.MX 7Dual SoC which I worked with lately includes the ARM Cortex-A7 CPU. The newer ARMv7 Cortex-A class cores such Cortex-A7, A15 and A17 come with a virtualization extensions which allow to use KVM (kernel virtual machine).
0 kommentar(er)
