Re: HVMLite / PVHv2 - using x86 EFI boot entry

["Luis R. Rodriguez" <mcgrof@suse.com>]

On Wed, Apr 06, 2016 at 12:07:36PM +0100, George Dunlap wrote:
> On Wed, Apr 6, 2016 at 3:40 AM, Luis R. Rodriguez <mcgrof@kernel.org> 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.

Forgive me, the private thread was ongoing and I really wanted to capture
both sides of the expressed arguments and move to the list any extensions
to the discussion, this meant annotating both positions and letting
others fill in the gaps to determine if in fact one position was really
nullified by the other.

First I should state that it is only natural for anyone sensible to have
any type of knee-jerk reaction to kick and scream about the idea of
adding yet a new x86 entry point for Linux... IMO one should not expect
it to be sensible to simply accept yet-another-entry-point to Linux,
rather is should be the expected behaviour to have people really dig
and ensure they did their homework to ensure that if they are going to
add yet-another-entry-point they really validate and have exhausted
review of all possible avenues.

It was Andrew Coopers's position that boot loaders would not need to be
involved, and that would seem to nullify Matt's original position on this.

While Andrew's position is right in that perhaps only Xen tools have to deal
with the HVMLite specific entry, it would also still mean diverging from ARM's
own EFI entry only position, which I'd like to clarify that ARM has no custom
Xen entry, we should strive to match that. Anything far from that to me really
deserves an explanation, specially if we are going to argue that HVMLite is
the best that x86 Xen can do.

Ultimately unifying entry approaches for Xen in a streamlined fashion seems
like a sensible thing to strive for. Anything we push in the other direction,
as small as it can be, should deserve at least a 'hey, wait a minute'...

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

Then you have not really read the document well, more to the point,
EFI's entry already does what the small HVMLite stub does, already
provides an existing entry and path to the kernel, so why should we
add yet another small stub?

So more to it, if the EFI entry already provides a way into Linux
in a more streamlined fashion bringing it closer to the bare metal
boot entry, why *would* we add another boot entry to x86, even if
its small and self contained ?

Another position against small stubs which I listed myself is that we may need
more semantics for early boot even if the new HVMLite small stub is added. This
remains to be seen. If we are going to add new semantics, it would seem best to
use something more standard like EFI configuration tables rather than hack on
to x86 further custom semantics. Custom sloppy semantics have proven to be
misused, and were ultimately a sloppy mess. To take this further,
virtualization semantics are being abused even outside of Xen -- drivers
developers may think that just because some semantics are available they can
use them to customize drivers to fine tune them for virtualized environments.
Even the best of our folks have taken positions to claim certain hacks are
*impossible* to change [0], when in fact only 4 days later a completely sensible
replacement was found [1], and this as even outside of Xen's situation, so its
not only Xen I am careful over here with regards to semantics. If we need early
boot code semantics or general kernel semantics for virtualization I want to
address that now and I want to be very careful with that given the abuse.
I'm doing my part to ensure that we clarify sloppy old semantics on Xen [2],
and this effort is actually proving to even pave the path for HVMLite, for
instance consider the gains of leveraging use of the legacy devices struct
in the future for ACPI_FADT_NO_VGA now, which HVMLite's specification seems
to annotate it will use. Clearing out the paravirt_enabled() hack for
pnpbios helped push for a right architectural solution to pave the path
for this in generic fashion.

[0] http://lkml.kernel.org/r/s5hvb4151v1.wl-tiwai@suse.de
[1] https://www.spinics.net/lists/alsa-devel/msg48627.html
[2] http://lkml.kernel.org/r/1459987594-5434-1-git-send-email-mcgrof@kernel.org

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

The purpose of the discussion is to evaluate the EFI entry as a possible
alternative candidate to yet another entry point, from a completely engineering
neutral position.

> That sounds like it's going to make the EFI path just as unmanageable as the
> current PV path.

Can you describe how?

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

How so? Please provide specifics.

  Luis

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