On 05/23/2013 12:52 PM, Albert ARIBAUD wrote:
Hi Andre,
On Mon, 6 May 2013 15:17:44 +0200, Andre Przywara
<[email protected]> 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.
_______________________________________________
U-Boot mailing list
[email protected]
http://lists.denx.de/mailman/listinfo/u-boot
