Message-ID: <20160413195257.GB1990@wotan.suse.de>
Date:	Wed, 13 Apr 2016 21:52:57 +0200
From:	"Luis R. Rodriguez" <mcgrof@...nel.org>
To:	George Dunlap <george.dunlap@...rix.com>
Cc:	Matt Fleming <matt@...eblueprint.co.uk>, jeffm@...e.com,
	Michael Chang <MChang@...e.com>,
	Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
	Jim Fehlig <jfehlig@...e.com>, Jan Beulich <JBeulich@...e.com>,
	"H. Peter Anvin" <hpa@...or.com>,
	Daniel Kiper <daniel.kiper@...cle.com>,
	the arch/x86 maintainers <x86@...nel.org>,
	Takashi Iwai <tiwai@...e.de>,
	Vojtěch Pavlík <vojtech@...e.cz>,
	Gary Lin <GLin@...e.com>,
	xen-devel <xen-devel@...ts.xenproject.org>,
	Jeffrey Cheung <JCheung@...e.com>,
	Juergen Gross <jgross@...e.com>,
	Stefano Stabellini <stefano.stabellini@...citrix.com>,
	joeyli <jlee@...e.com>, Borislav Petkov <bp@...en8.de>,
	Boris Ostrovsky <boris.ostrovsky@...cle.com>,
	Charles Arndol <carnold@...e.com>,
	Andrew Cooper <andrew.cooper3@...rix.com>,
	Julien Grall <julien.grall@....com>,
	Andy Lutomirski <luto@...capital.net>,
	"Luis R. Rodriguez" <mcgrof@...nel.org>,
	David Vrabel <david.vrabel@...rix.com>,
	Linus Torvalds <torvalds@...ux-foundation.org>,
	Roger Pau Monné <roger.pau@...rix.com>
Subject: Re: [Xen-devel] HVMLite / PVHv2 - using x86 EFI boot entry

On Wed, Apr 13, 2016 at 04:44:54PM +0100, George Dunlap wrote:
> On Thu, Apr 7, 2016 at 7:51 PM, Luis R. Rodriguez <mcgrof@...e.com> 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:

And this is what I was looking for, thanks!

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

That's on the EFI Linux maintainer to assess. And he seems willing to
consider this.

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

This seems to be a good sticking point, but Andi noted another aspect
of this or redundancy as well.

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

What if this is an option only then ?

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

What if this is an option only then ?

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

Not true:

  * Avoiding code duplication
  * Semantics may be needed anyway


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

Part of my engagement on HVMLite review is *because* I have been posting
code to help proactively address some old classic PV path issues and
semantics.

I've been addressing semantics on the PV path, and trying to help
bring the classic PV path closer to native entry points while trying
to also provide a proactive measure to help address regressions on the
classic PV path without having Xen be a bottleneck for x86 development.

As for the EFI stuff -- its discussion now as it'd be pointless to
throw out code if we already know we can't go down a path.

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

That's because of sloppy solutions.

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

You seem to be missing the points I've raised to Boris about semantics
and requirements for custom platform stuff.

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

Quite the contrary! It does, the question is how we are going to address
the semantics clearly. EFI seemed to provide an OS agnostic way to
address some of this through configuration tables, which would mean
not having to extend the old x86 boot protocol further. More to the
point, this is beyond x86, if we are going to be striving to unify
entry points on Linux across architectures in the long term why not
start addressing needed semantics for virtualization through more
standard mean now?

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

And he is, but privately shared so far. We still can benefit from
more architectural discussion over these things.

  Luis

Powered by blists - more mailing lists