Re: [Xen-devel] HVMLite / PVHv2 - using x86 EFI boot entry

[George Dunlap <george.dunlap@xxxxxxxxxx>]

On Wed, Apr 6, 2016 at 3:40 AM, Luis R. Rodriguez <mcgrof@xxxxxxxxxx> wrote:
> 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.
[snip]
>   * Issues with boot x86 boot entries
>     * Small x86 zero page stubs
[snip]
>   * Points against using EFI
>     * Nulling the claimed boot loader effect

I'm a bit confused about this. You list exactly two arguments against
the proposed stub in the "con" section:
1. Bootloaders may not be able to use the extra entry point
2. It's an extra entry point

And then later, in another section, you actually list the reason #1 is
irrelevant: bootloaders don't matter because the stub is there to boot
from the Xen hypervisor.

So the only actual argument you have against the proposed PVH stub in
the linked document is that it's an extra entry point.

>   * 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

So rather than make a new entry point which does just the minimal
amount of work to run on a software interface (Xen), you want to take
an interface designed for hardware (EFI) and put in hacks so that it
knows that sometimes some EFI services are not available?  That sounds
like it's going to make the EFI path just as unmanageable as the
current PV path.

Using the EFI entry point would certainly make sense if it was
actually simpler than the proposed extra entry point.  But it sounds
like it's going to be more complicated, not only for Xen, but also for
Linux.

 -George

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel