[U-Boot] [PATCH 0/6] ARMv7: Add HYP mode switching support

[Andre Przywara]

On 05/23/2013 12:52 PM, Albert ARIBAUD wrote:
> Hi Andre,
>
> On Mon,  6 May 2013 15:17:44 +0200, Andre Przywara
> <andre.przywara at linaro.org> 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:

Not silly at all, keep asking!

> - what happens if a target with these patches actually starts with HYP
>    already enabled by some secure ROM boot code?

If HYP mode is already enabled, then armv7_switch_hyp() returns early 
(the 3rd last hunk in patch 5), so that actually no code from that 
series is ever executed.
But thinking about it again I see that I write MVBAR before the check, I 
think it is not necessary to do it that early. Will check this again and 
send out a fixed version.

Also the idea was that the CONFIG_ option is only set on boards for 
which one knows that they enter u-boot in secure state. If ROM code 
already enabled HYP, then this code is not necessary and doesn't need to 
be configured.
Originally I wanted to have truly universal code, but since we need to 
configure u-boot for a specific board anyway and also there is no easy 
way to determine whether we already are non-secure I gave up on this for 
the time being. Not sure if using something like catching the UNDEF 
exception and returning to the code with an error condition (like 
wrmsr_safe in Linux/x86) is worth being added.

> - 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?

If board firmware offers mandatory secure functionalities (like the PSCI 
interface), then this firmware should better go to HYP itself, otherwise 
there is no way to do this without being secure first (we need to set 
HVBAR, this only works from monitor or HYP mode). Another option would 
be to use a secure service routine offered by the secure ROM code to set 
this HVBAR register. This would be board specific, I guess. If there is 
such a board, I'd be happy to hear about it and add support for it.

Regards,
Andre.