[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <5710BD0B.2070306@arm.com>
Date: Fri, 15 Apr 2016 11:06:03 +0100
From: Julien Grall <julien.grall@....com>
To: "Luis R. Rodriguez" <mcgrof@...nel.org>,
Konrad Rzeszutek Wilk <konrad.wilk@...cle.com>
Cc: Juergen Gross <jgross@...e.com>,
Matt Fleming <matt@...eblueprint.co.uk>,
Michael Chang <MChang@...e.com>, 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>, x86@...nel.org,
Vojtěch Pavlík <vojtech@...e.cz>,
Gary Lin <GLin@...e.com>, xen-devel@...ts.xenproject.org,
Jeffrey Cheung <JCheung@...e.com>,
Stefano Stabellini <sstabellini@...nel.org>,
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>,
Andy Lutomirski <luto@...capital.net>,
David Vrabel <david.vrabel@...rix.com>,
Linus Torvalds <torvalds@...ux-foundation.org>,
Roger Pau Monné <roger.pau@...rix.com>,
Josh Triplett <josh@...htriplett.org>,
Kees Cook <keescook@...omium.org>,
Vitaly Kuznetsov <vkuznets@...hat.com>
Subject: Re: [Xen-devel] HVMLite / PVHv2 - using x86 EFI boot entry
Hello Luis,
On 14/04/16 21:56, Luis R. Rodriguez wrote:
> On Thu, Apr 14, 2016 at 03:56:53PM -0400, Konrad Rzeszutek Wilk wrote:
>> On Thu, Apr 14, 2016 at 08:40:48PM +0200, Luis R. Rodriguez wrote:
>>> On Wed, Apr 13, 2016 at 09:01:32PM -0400, Konrad Rzeszutek Wilk wrote:
>>>> On Thu, Apr 14, 2016 at 12:23:17AM +0200, Luis R. Rodriguez wrote:
>>> PV support from the kernel (not the hypervisor) and require hardware
>>> virtualization 5 years from now on the Linux kernel, it doesn't seem
>>> to me far fetched to at the very least consider using an EFI entry
>>> instead, specially since all it does is set boot params and we can
>>> make re-use this for HVMLite too.
>>
>> 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.
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. 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.
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.
Regards,
[1] Documentation/arm/uefi.txt in Linux.
[2]
http://xenbits.xen.org/docs/unstable-staging/misc/arm/device-tree/guest.txt
[3] http://www.gossamer-threads.com/lists/xen/devel/397349
--
Julien Grall
Powered by blists - more mailing lists