On Tue, Aug 23, 2011 at 11:12 PM, Catalin Marinas
<catalin.marinas at arm.com>wrote:
> On 23 August 2011 18:23, Ian Jackson <Ian.Jackson at eu.citrix.com> wrote:
> > Catalin Marinas writes ("Re: ARM processor mode, kernel startup, Hyp /
> secure state"):
> >> We had some discussions both with ARM partners and Christoffer and it
> >> is not clear how we go about initialising the Hyp mode. Most SoC
> >> vendors would probably just run Linux in non-secure SVC mode and would
> >> not touch the Hyp mode at all. Linux would issue an SMC to set the
> >> HVBAR (could do HVC but I expect that there is no secure monitor
> >> code). Once this is set, assuming that the Hyp MMU is disabled, Linux
> >> can invoke an HVC and initialise the Hyp mode.
> >
> > Well, yes. Do SoC vendors all expect to own the secure state ?
>
> Maybe some parts of it, that's why it's hard to standardise some kind
> of API. Since the platform boots in secure mode, they need at least
> some code which they own, in addition to other stuff like secure
> transactions.
>
> > If so then the answer is perhaps simply that they should boot Linux in
> > Hyp mode (and expect Linux to drop to ordinary svc mode).
>
> That would be a solution as it is relatively simple for Linux to check
> the mode and switch to SVC. The issue I see is that Linux is not the
> first non-secure code to run but you usually get some boot loader like
> U-Boot. You would have to make the latter aware of the Hyp mode as
> well and many SoC vendors may not be willing to put the effort in (we
> can help by providing boot loader fixes but the boot loader may not
> always be open source).
I second that booting in Hyp mode seems like a clean solution, although I'm
not an export on U-Boot. What I think we want to avoid is being unable to
use KVM on a platform, that has the architecture virtualization support, due
to the boot process and an incompatible API.
However, there's no way to use Hyp mode without _some_ support from the
earlier stages in the boot process am I right? In that case, the question is
simply whether we should expect platforms to boot the kernel in Hyp mode or
if we can expect vendors to agree on a stable secure monitor API for
initializing Hyp mode.
Personally I don't care either way and it won't effect the implementation of
KVM in any significant way. Worst case, we can have a common in-kernel API
that sets the HVBAR through either method depending on the platform, but
would be great if this could be avoided.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: https://lists.cs.columbia.edu/pipermail/android-virt/attachments/20110823/5152a288/attachment.html
