HVMLite / PVHv2 - using x86 EFI boot entry

["Luis R. Rodriguez" <mcgrof@kernel.org>]

Boris sent out the first HVMLite series of patches to add a new Xen guest type
February 1, 2016 [0]. We've been talking off list with a few folks now over
the prospect of instead of adding yet-another-boot-entry we instead fixate
HVMLite to use the x86 EFI boot entry. There's a series of reasons to consider
this, likewise there are reasons to question the effort required and if its
really needed. We'd like some more public review of this proposal, and see if
others can come up with other ideas, both in favor or against this proposal.

This in particular is also a good time to get x86 Linux folks to chime on on
the general design proposal of HVMLite design, given that outside of the boot
entry discussion it would seem including myself that we didn't get the memo
over the proposed architecture review [1]. At least on my behalf perhaps the
only sticking thorns of the design was the new boot entry, which came to me
as a surprise, and this thread addresses and the lack of addressing semantics 
for early boot (which we may seem to need to address; some of this is being
addressing in parallels through other work). The HVMLite document talks about
using ACPI_FADT_NO_VGA -- we don't use this yet upstream but I have some pending
changes which should make it easy to integrate its use on HVMLite. Perhaps
there are others that may have some other points they may want to raise now...

A huge summary of the discussion over EFI boot option for HVMLite is now on a
wiki [2], below I'll just provide the outline of the discussion. Consider this a
request for more public review, feel free to take any of the items below and
elaborate on it as you see fit.

Worth mentioning also is that this topic will be discussed at the 2016 Xen
Hackathon April 18-19 [3] at the ARM Cambridge, UK Headquarters so if you can
attend and this topic interests you, consider attending.

  * Linux x86 Xen EFI boot entry evaluation
  * Issues with boot x86 boot entries
    * Bypassing native startup_32() / startup_64()
    * Small x86 zero page stubs

  * Xen evolution and roadmap
    * About PVH
    * About HVMLite
    * Xen ARM solution

  * Why use EFI for HVMlite
    * EFI calling conventions are standardized
    * EFI entry generalizes what new HVMLite entry proposes
    * Further semantics may be needed
    * Match Xen ARM's clean solution
    * You don't need full EFI emulation
      * Minimal EFI stubs for guests
        * GetMemoryMap()
        * ExitBootServices()
      * EFI stubs which may be needed for guests
        * Exit()
        * Variable operation functions
      * EFI stubs not needed for guests
        * GetTime()/SetTime()
        * SetVirtualAddressMap()
        * ResetSystem()
      * dom0 EFI
      * domU EFI emulation possibilities
        * Xen implements its own EFI environment for guests
        * Xen uses Tianocore / OVMF
    * kexec needs a boot path as well

  * Points against using EFI
    * Legacy PV guests need to be supported
    * Nulling the claimed boot loader effect
    * startup_32 / startup_64 flexibility
  * Remaining questions

[0] http://lkml.kernel.org/r/1454341137-14110-3-git-send-email-boris.ostrovsky@oracle.com
[1] http://lists.xen.org/archives/html/xen-devel/2016-02/msg01609.html
[2] http://kernelnewbies.org/KernelProjects/x86-xen-efi
[3] http://wiki.xenproject.org/wiki/Hackathon/April2016

  Luis