On Tue, Aug 23, 2011 at 11:12 PM, Catalin Marinas
<catalin.marinas@arm.com> wrote:
On 23 August 2011 18:23, Ian Jackson <
Ian.Jackson@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.