[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

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.
>   * Issues with boot x86 boot entries
>     * Small x86 zero page stubs
>   * 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


Xen-devel mailing list



Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.