Re: [Xen-devel] [PATCH v3 10/16] efi: create efi_enabled()

[Daniel Kiper <daniel.kiper@xxxxxxxxxx>]

On Fri, May 27, 2016 at 02:22:39AM -0600, Jan Beulich wrote:
> >>> On 25.05.16 at 19:15, <daniel.kiper@xxxxxxxxxx> wrote:
> > On Wed, May 25, 2016 at 01:20:23AM -0600, Jan Beulich wrote:
> >> >>> On 15.04.16 at 14:33, <daniel.kiper@xxxxxxxxxx> wrote:

[...]

> >> > --- a/xen/include/xen/efi.h
> >> > +++ b/xen/include/xen/efi.h
> >> > @@ -2,15 +2,17 @@
> >> >  #define __XEN_EFI_H__
> >> >
> >> >  #ifndef __ASSEMBLY__
> >> > +#include <xen/bitops.h>
> >> >  #include <xen/types.h>
> >> >  #endif
> >> >
> >> > -extern const bool_t efi_enabled;
> >> > -
> >> >  #define EFI_INVALID_TABLE_ADDR (~0UL)
> >> >
> >> > +#define EFI_PLATFORM    0
> >>
> >> So what does "platform" mean? Did you consider using the more fine
> >
> > It means "EFI platform". It differentiates from "legacy BIOS platform".
>
> Well, that's what was clear from the beginning. The question however
> was (taken together with the second one) what it means functionality
> wise. The later addition makes clear it doesn't mean "loaded directly

This means that we run on EFI platform and we can use its features,
e.g. runtime services, get info from it about ACPI, SMBIOS, etc.

> from EFI". But looking at the various flags Linux has here, what

Yep.

> functionality does it imply? Does it e.g. mean runtime services are to
> be used? If so, the flag would need to be cleared when their use if

As above: not only.

> being suppressed.

If we need that (e.g. for ARM) then we should create e.g. EFI_RS.

> >> grained set of flags Linux uses nowadays? That would also eliminate
> >
> > I wish to use just basic idea. However, I am not going to copy all
> > stuff from Linux. We do not need that.
>
> We don't need all of it, sure. But some more fine grained
> identification of what functionality is available / to be used
> would surely benefit us as a whole and your patch series in
> particular.

As above.

Daniel

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