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

[George Dunlap <george.dunlap@xxxxxxxxxx>]

On Thu, Apr 7, 2016 at 7:51 PM, Luis R. Rodriguez <mcgrof@xxxxxxxx> wrote:
> 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 ?

We would avoid using EFI if:

* Being called both on real hardware and under Xen would make the EFI
entry point more complicated

* Adding the necessary EFI support into Xen would be a significant
chunk of extra work

* Requiring PVH mode to implement EFI would make it more difficult for
other kernes (NetBSD, FreeBSD) to act as dom0s.

* Requiring PVH mode to use EFI would make it more difficult to
support unikernel-style workloads for domUs.

Now as has been pointed out, we don't know for a lot of the above
things for certain, because nobody has posted any code.  None of us
really want to post any code because:

* Reading and understanding the EFI spec, the Linux EFI path, and
implementing all that on both the Xen and the Linux side is a lot of
work

* It looks pretty likely that many of the above things will be true

* The only real objection to the currently proposed solution is really weak.

If you want to post some code I'm sure we could give you feedback on it.

> 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.
[snip]
>> 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.

Here is the juxtaposition that confuses me.  The problem with a lot of
the current code is that you have virtualization-specific hacks all
over the place making things complicated.  And in the first quote
above, you seem afraid that the extra entry point with stub code will
somehow be misused and end up in a similar "sloppy mess", even though
it's not at all clear how *having a stub entry point* could be
"abused" by anyone.  But then when I suggest that sharing a codepath
between systems that have actual EFI firmware, with platform hardware,
and a system that has no EFI firmware and no similar concept of the
hardware, might end up a sloppy mess of Xen-specific if clauses and
maintenance headaches due to broken assumptions, it doesn't even
register with you as a reasonable concern?

As Matt said, nobody will be able to provide specifics until someone
tries to code it up.  But coding things up is not free.

 -George

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