Hi Andre,
On Mon, 6 May 2013 15:17:44 +0200, Andre Przywara
<andre.przywara@xxxxxxxxxx> wrote:
> (for GIT URL and Changelog see below)
>
> ARM CPUs with the virtualization extension have a new mode called
> HYP mode, which allows hypervisors to safely control and monitor
> guests. The current hypervisor (KVM and Xen) implementations
> require the kernel to be entered in that HYP mode.
>
> This patch series introduces a configuration variable
> CONFIG_ARMV7_VIRT which enables code to switch all cores into HYP
> mode. This is done automatically during execution of the bootm
> command (but could also be done earlier - U-Boot runs fine in HYP
> mode without MMU usage).
>
> The process of switching into HYP mode requires the CPU to be in
> non-secure state, which requires the GIC to be programmed properly
> first. Explanations about the details are in the commit messages
> of the respective patches.
>
> The code aims to be as generic as possible, though currently it has
> only been tested on the Versatile Express TC-2 board. The last patch
> thus enables the feature for that board and relies on the Versatile
> Express updates patches sent out lately[1].
>
> For convenience there is now a GIT tree which you can pull these
> and the Versatile Express patches from ("hypmode" branch):
> git://git.linaro.org/people/aprzywara/u-boot.git
>
> Changes from the RFC version I sent out before:
> * not a dedicated command anymore, code run by bootm & friends
> * protecting code with #ifdefs to avoid unnecessary inclusion and
> accidental crashing (when accessing restricted registers)
> * moving prototypes to header file to meet checkpatch recommendation
> * adding comment as proposed by Christoffer
>
> Please review and comment!
> Contributions and comments to support other boards are welcome.
I know... virtually... nothing in virtualization, so please excuse any
silly questions below:
- what happens if a target with these patches actually starts with HYP
already enabled by some secure ROM boot code?
- I thought that once HYP is enabled, then all secure functionalities
are performed by some monitor code invoked through a sw exception. Is
the swi handler this monitor code? If it is, then is this monitor
crippled, and what will happen if the bootm code needs to use some
secure functionality?
> Andre.
Amicalement,
--
Albert.
_______________________________________________
kvmarm mailing list
kvmarm@xxxxxxxxxxxxxxxxxxxxx
https://lists.cs.columbia.edu/cucslists/listinfo/kvmarm
