Catalin Marinas writes ("Re: ARM processor mode, kernel startup, Hyp / secure state"):
(I'll be on holiday from tomorrow, so not able to follow up until September).
Right. Let's try to be quick :-).
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 ?
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).
The problem is that the SMC API is specific to a secure monitor implementation. An alternative would be to ask the vendors to get some simple Hyp code which would trap access to HVBAR for example and set it with that value.
That's seems to be extending the range of ways in which the firmware can make things go wrong, and broadening the interface to the firmware.
From the above, I would just allow (iii). As Dave pointed out, we don't have the ELF information at this point.
If we had a more functional bootloader setup (which AIUI is definitely planned) we could do.
(b) If started in Hyp mode: * Install a trivial hypervisor vector which unconditionally copies r0 to HVBAR and returns (c) Rest of startup.
Maybe we could allow (b) if SoC vendors don't provide a different API to set the HVBAR. But it means that kernels not aware of this feature would fail.
It turns out that at least your kernel boots just fine if started in Hyp mode :-).
Ian.