Date:	Mon, 11 Apr 2016 07:12:08 +0200
From:	Juergen Gross <jgross@...e.com>
To:	"Luis R. Rodriguez" <mcgrof@...nel.org>,
	David Vrabel <david.vrabel@...rix.com>,
	Julien Grall <julien.grall@....com>,
	Stefano Stabellini <stefano.stabellini@...citrix.com>
Cc:	Andrew Cooper <andrew.cooper3@...rix.com>,
	Boris Ostrovsky <boris.ostrovsky@...cle.com>,
	Roger Pau Monné <roger.pau@...rix.com>,
	Matt Fleming <matt@...eblueprint.co.uk>,
	Charles Arndol <carnold@...e.com>,
	Jim Fehlig <jfehlig@...e.com>, Jan Beulich <JBeulich@...e.com>,
	Daniel Kiper <daniel.kiper@...cle.com>,
	"H. Peter Anvin" <hpa@...or.com>, x86@...nel.org,
	Gary Lin <GLin@...e.com>,
	Andy Lutomirski <luto@...capital.net>,
	Borislav Petkov <bp@...en8.de>, joeyli <jlee@...e.com>,
	Jeffrey Cheung <JCheung@...e.com>,
	Michael Chang <MChang@...e.com>,
	Vojtěch Pavlík <vojtech@...e.cz>,
	linux-kernel@...r.kernel.org, xen-devel@...ts.xenproject.org,
	Linus Torvalds <torvalds@...ux-foundation.org>
Subject: Re: HVMLite / PVHv2 - using x86 EFI boot entry

On 08/04/16 22:40, Luis R. Rodriguez wrote:
> On Wed, Apr 06, 2016 at 10:40:08AM +0100, David Vrabel wrote:
>> On 06/04/16 03:40, Luis R. Rodriguez wrote:
>>>
>>>     * You don't need full EFI emulation
>>
>> I think needing any EFI emulation inside Xen (which is where it would
>> need to be for dom0) is not suitable because of the increase in
>> hypervisor ABI.
> 
> Is this because of timing on architecture / design of HVMLite, or
> a general position that the complexity to deal with EFI emulation
> is too much for Xen's taste ?

The Xen hypervisor should be as small as possible. Adding an EFI
emulator will be adding quite some code. This should be done after a
very thorough evaluation only.

> ARM already went the EFI entry way for domU -- it went the OVMF route,
> would such a possibility be possible for x86 domU HVMLite ? If not why
> not, I mean it would seem to make sense to at least mimic the same type
> of early boot environment, and perhaps there are some lessons to be
> learned from that effort too.

The final solution must be appropriate for dom0, too. So don't try
to limit the discussion to domU. If dom0 isn't going to be acceptable
there will no need to discuss domU.

> Are there some lessons to be learned with ARM's effort? What are they?
> If that could be re-done again with any type of cleaner path, what
> could that be that could help the x86 side ?
> 
> Although emulating EFI may require work, some folks have pointed out
> that the amount of work may not be that much. If that is done can
> we instead rely on the same code to replace OVMF to support both
> Xen ARM and Xen HVMLite on x86 ? What would be the pros / cons of
> this ?
> 
>> I also still do not understand your objection to the current tiny stub.
> 
> Its more of a hypothetical -- can an EFI entry be used instead given
> it already does exactly what the new small entry does ? Its also rather
> odd to add a new entry without evaluating fully a possible alternative
> that would provide the same exact mechanism.

The interface isn't the new entry only. It should be evaluated how much
of the early EFI boot path would be common to the HVMlite one. What
would be gained by using the same entry but having two different boot
paths after it? You still need a way to distinguish between bare metal
EFI and HVMlite. And Xen needs a way to find out whether a kernel is
supporting HVMlite to boot it in the correct mode.

> A full technical unbiased evaluation of the different approaches is what I'd
> hope we could strive to achieve through discussion and peer review, thinking
> and prioritizing ultimately what is best to minimize the impact on Linux
> and also help take advantage of the best features possible through both
> means. Thinking long term, not immediate short term.

Sure.


Juergen

Powered by blists - more mailing lists