[U-Boot] [PATCH v5 7/8] ARM: extend non-secure switch to also go into HYP mode

[Christoffer Dall <christoffer.dall@linaro.org>]

On Thu, Oct 03, 2013 at 08:24:57AM +0200, Albert ARIBAUD wrote:
> Hi Andre,
> 
> On Thu, 19 Sep 2013 18:06:45 +0200, Andre Przywara
> <andre.przywara@linaro.org> wrote:
> 
> > For the KVM and XEN hypervisors to be usable, we need to enter the
> > kernel in HYP mode. Now that we already are in non-secure state,
> > HYP mode switching is within short reach.
> > 
> > While doing the non-secure switch, we have to enable the HVC
> > instruction and setup the HYP mode HVBAR (while still secure).
> > 
> > The actual switch is done by dropping back from a HYP mode handler
> > without actually leaving HYP mode, so we introduce a new handler
> > routine in our new secure exception vector table.
> > 
> > In the assembly switching routine we save and restore the banked LR
> > and SP registers around the hypercall to do the actual HYP mode
> > switch.
> > 
> > The C routine first checks whether we are in HYP mode already and
> > also whether the virtualization extensions are available. It also
> > checks whether the HYP mode switch was finally successful.
> > The bootm command part only calls the new function after the
> > non-secure switch.
> > 
> > Signed-off-by: Andre Przywara <andre.przywara@linaro.org>
> > ---
> >  arch/arm/cpu/armv7/Makefile      |  2 +-
> >  arch/arm/cpu/armv7/nonsec_virt.S | 43 +++++++++++++++++++++++++++++++++++-----
> >  arch/arm/cpu/armv7/virt-v7.c     | 37 ++++++++++++++++++++++++++++++++++
> >  arch/arm/include/asm/armv7.h     |  6 ++++--
> >  arch/arm/lib/bootm.c             |  7 ++++++-
> >  5 files changed, 86 insertions(+), 9 deletions(-)
> > 
> > Changes:
> > v3..v4: w/s fixes, embed error output
> > v4..v5: none
> 
> Seems like Christoffer's comment was not addressed here but IIUC, it
> was in other files (Christoffer, feel free to comment). Any reason why
> the "older asm" comments form was not replaced in here?
>   

I think these comments are a bit superflous, but not exactly harmful, so
I didn't raise the flag when they were not corrected.  My thought was
that if you're building for a board that has support for the
virtualization extensions you should be using a toolchain that knows
about them too, but Andre pointed out that his (I think Debian) still
used an old enough cross toolchain not to have this support.

In any case, I don't think this warrants holding back the patches but
can be fixed as a follow-up if the community agrees that we need to
support older toolchains by some define that encodes the hvc and eret
instructions properly.

Thanks,
-Christoffer