Re: HVMLite / PVHv2 - using x86 EFI boot entry

From: "Luis R. Rodriguez" <mcgrof@kernel.org>
To: Julien Grall <julien.grall@arm.com>
Cc: "Matt Fleming" <matt@codeblueprint.co.uk>,
	"Michael Chang" <MChang@suse.com>,
	"Jim Fehlig" <jfehlig@suse.com>,
	"Jan Beulich" <JBeulich@suse.com>,
	"H. Peter Anvin" <hpa@zytor.com>,
	"Stefano Stabellini" <sstabellini@kernel.org>,
	"Daniel Kiper" <daniel.kiper@oracle.com>,
	"X86 ML" <x86@kernel.org>, "Vojtěch Pavlík" <vojtech@suse.cz>,
	"Gary Lin" <GLin@suse.com>,
	xen-devel <xen-devel@lists.xenproject.org>,
	"Jeffrey Cheung" <JCheung@suse.com>,
	"Charles Arndol" <carnold@suse.com>,
	"Kees Cook" <keescook@chromium.org>,
	"Josh Triplett" <josh@joshtriplett.org>, joeyli <jlee@suse.com>,
	"Borislav Petkov" <bp@alien8.de>,
	"Boris Ostrovsky" <boris.ostrovsky@oracle.com>,
	"Juergen Gross" <jgross@suse.com>,
	"Andrew Cooper" <andrew.cooper3@citrix.com>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	"Andy Lutomirski" <luto@amacapital.net>,
	"David Vrabel" <david.vrabel@citrix.com>
Subject: Re: HVMLite / PVHv2 - using x86 EFI boot entry
Date: Fri, 15 Apr 2016 07:55:39 -0700	[thread overview]
Message-ID: <CAB=NE6UDuLOnW8xfTcgCGSbJ1aS4TkkokcGdeJGHMBps0T9=Sg__21510.4292998605$1460732246$gmane$org@mail.gmail.com> (raw)
In-Reply-To: <5710BD0B.2070306@arm.com>

On Fri, Apr 15, 2016 at 3:06 AM, Julien Grall <julien.grall@arm.com> wrote:
> On 14/04/16 21:56, Luis R. Rodriguez wrote:
>> On Thu, Apr 14, 2016 at 03:56:53PM -0400, Konrad Rzeszutek Wilk wrote:
>>> But to make that work you have to emulate EFI firmware in the
>>> hypervisor. Is that work you are signing up for?
>>
>> I'll do what is needed, as I have done before. If EFI is on the long
>> term roadmap for ARM perhaps there are a few birds to knock with one
>> stone here. If there is also interest to support other OSes through
>> EFI standard means this also should help make that easier.
>
> We already have a working solution for EFI on ARM which does not require to
> emulate the firmware in the hypervisor.

I get that.

> On ARM, the EFI stub is communicating with the kernel using device-tree [1].
> Once the EFI stub has ended, the native path (i.e non-UEFI) will be executed
> normally and it won't be possible to use BootServices anymore.
>
> For the guest, we provide a full support of EFI using OVMF.

I get that as well, is this the long term solution ? That still
requires OVMF, will relying on OVMF always be what is used on Xen ARM
? Was it too much of a burden to require OVMF? Is the upstream OVMF
code pulled by Xen at build time on ARM, or just wget a binary ?

> For DOM0, Xen
> will craft the UEFI system table and the UEFI memory map. The locations of
> those tables will be passed to DOM0 using a tiny device-tree [1] and the
> kernel will boot using the native path. The runtime services for DOM0 will
> be provided via hypercall.

Thanks this helps!

> The DOM0 approach has been discussed for a long time (see [3]) and I believe
> this is better than emulating UEFI firmware in Xen. We want to keep Xen on
> ARM tiny. Adding any sort of emulation will increase the attack surface and
> require more maintenance from our side.

OK thanks, would re-using OVMF (note, DT perhaps may not be ideal for
x86 for the rest though) be a reasonable solution on x86 as an option
then?

  Luis

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