[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Xen-devel] [PATCH 05/18] efi: split efi_enabled to efi_platform and efi_loader

On 27/03/15 13:43, Jan Beulich wrote:
On 27.03.15 at 14:32, <daniel.kiper@xxxxxxxxxx> wrote:
On Fri, Feb 20, 2015 at 04:17:35PM +0000, Jan Beulich wrote:
On 30.01.15 at 18:54, <daniel.kiper@xxxxxxxxxx> wrote:
We need more fine grained knowledge about EFI environment and check
for EFI platform and EFI loader separately to properly support
multiboot2 protocol.
... because of ... (i.e. I can't see from the description what the
separation is good for). Looking at the comments you placed
aside the variables doesn't help me either.

In general Xen loaded by this protocol uses
memory mappings and loaded modules in simliar way to Xen loaded
by multiboot (v1) protocol. Hence, split efi_enabled to efi_platform
and efi_loader.
And if I'm guessing things right, then introducing efi_loader but
leaving efi_enabled alone (only converting where needed) would
efi_enabled is not fortunate name for new usage. Currently it means
that Xen binary have or does not have EFI support build in. However,
if we build in multiboot2 protocol into xen.gz then it means that
it can ran on legacy BIOS or EFI platform. So, I think that we
should rename efi_enabled to efi_platform because it will mean
that Xen runs on EFI platform or not.
I disagree here.

efi_loader is used to differentiate between EFI native loader
and multiboot2 protocol.
And I agree here.

I suppose "built with efi support" is known because of CONFIG_EFI or not, and doesn't need a variable.

However, "booted legacy" vs "booted EFI" does need distinguishing at runtime, as either is possible.


Xen-devel mailing list



Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.