Re: HVMLite / PVHv2 - using x86 EFI boot entry

[Stefano Stabellini <sstabellini@kernel.org>]

On Fri, 15 Apr 2016, Luis R. Rodriguez wrote:
> 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 ?

Yes, it is for Xen on ARM.


> That still requires OVMF, will relying on OVMF always be what is used
> on Xen ARM ?

Not always, the native boot path is still supported. It is possible to
boot a VM using "kernel=/path/to/linux" in your VM config file and that
is not going to boot via EFI but via the native boot path.

To summarize, on ARM:

# DomUs options:
1) xl create "kernel=/path/to/ovfm.bin" -> OVMF -> EFI stub -> Linux (regular entry point)
2) xl create "kernel=/path/to/Linux" -> Linux (regular entry point)

# Dom0 options:
1) native UEFI firmare -> Xen (ExitBootServices) -> Linux (regular entry point)
2) uBoot -> Xen -> Linux (regular entry point)


> Was it too much of a burden to require OVMF?

No, it wasn't. Especially because Anthony had already introduced Xen
support in it.


> Is the upstream OVMF code pulled by Xen at build time on ARM, or just
> wget a binary ?

At the moment the build is not integrated, so you need to go and build
it yourself or use Raisin to do it.


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

Reusing OVMF for HVMLite DomUs should be easy and something to look at
in the future. Reusing OVMF for HVMLite Dom0 is another story. I think
is a bad idea.

If we wanted to do something like we did on ARM, we need to understand
how the Linux internal API on x86 between the EFI stub and the regular
entry point look like. Is there even one? Could we elevate that to an
external interface and use it to boot Linux from Xen? If so, that would
be an option.

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