Ian, (I'll be on holiday from tomorrow, so not able to follow up until September). On 23 August 2011 15:52, Ian Jackson <Ian.Jackson at eu.citrix.com> wrote: > We're looking into porting Xen to the ARM A15 architecture. ?In this > context, it's necessary to arrange for the Xen hypervisor to be > entered from the boot loader in an appropriate processor mode. 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. 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. > So I propose the following approach: > > ?1. The kernel will advertise via ELF notes what modes it may be > ? ?started in. ?The possible modes will be: > ? ? ? (i) ? secure monitor mode > ? ? ? (ii) ?non-secure hypervisor mode > ? ? ? (iii) non-secure kernel mode >From the above, I would just allow (iii). As Dave pointed out, we don't have the ELF information at this point. > ?2. The bootloader will select the first mode from the three listed > ? ?above which is supported by both the processor and the kernel to > ? ?be loaded, and transition the processor to that mode. ?If this > ? ?involves dropping out of secure or hypervisor mode, it will put > ? ?those modes permanently beyond use. I'm not considering this step because of my point above. > ?3. The kernel will examine CPSR to determine which of the three > ? ?possibilities above has happened, and: > ? (a) If started in monitor mode: > ? ? ? * Grant access to everything to non-secure state > ? ? ? * Set the non-secure copies of the various CP15 registers > ? ? ? ? which don't have a sane value on cpu reset > ? ? ? * Install a trivial monitor vector which unconditionally > ? ? ? ? copies r0 to MVBAR and returns > ? ? ? * Switch to non-secure Hyp mode (if available) and do (b), > ? ? ? ? or non-secure Kernel mode (if Hyp mode not supported). > ? (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. -- Catalin
