No subject

and various bootloader people, it looks like we have two scenarios [this is
reiterating a lot of what you've said but I think it's important]:


  After the system has taken care of whatever secure initialisation was
  required, it moves into HYP mode. At this point there are two things that
  can happen:

  1.0: HYP mode boot loader (uboot, UEFI) runs and installs Linux at the
       same privilege level
  1.1: Raw Linux boots, and detects HYP mode
  1.2: Sets up basic init, with HVC trampoline for installing KVM/Xen later
  1.3: Switch to SVC mode
  1.4: Continue booting Linux as normal

  Or:

  2.0: HYP layer installed as part of system firmware
  2.1: Hypervisor system init, HVC handlers installed
  2.2: Switch to SVC mode
  2.3: SVC mode boot loader (uboot, UEFI) runs and installs Linux
  2.4: Linux boots as normal


Obviously, as kernel developers, we prefer the first approach because it
gives us control over the HYP interface. In practice, I expect to see
some platforms that take the second approach and I think that we have to
support it. The best we can hope for in this case is that the HVC layer
has an API for installing another hypervisor. If that API is standardised,
then even better.

Unlike the fragmented secure monitor API that currently exists across
different platforms, it's really in the interests of the vendor to
standardise on the HYP interface and provide calls to install code, otherwise
they run the risk of producing what is essentially a closed system.

Will