Re: [Xen-devel] Usage of efi_enabled - Was: Re: [PATCH RFC 33/35] arm : acpi enable efi for acpi

["Jan Beulich" <JBeulich@xxxxxxxx>]

>>> On 11.02.15 at 11:49, <ian.campbell@xxxxxxxxxx> wrote:
> On Wed, 2015-02-11 at 10:28 +0000, Jan Beulich wrote:
>> >>> On 11.02.15 at 10:51, <julien.grall@xxxxxxxxxx> wrote:
>> >> --- a/xen/common/efi/runtime.c
>> >> +++ b/xen/common/efi/runtime.c
>> >> @@ -11,7 +11,13 @@ DEFINE_XEN_GUEST_HANDLE(CHAR16);
>> >>   #ifndef COMPAT
>> >>
>> >>   #ifdef CONFIG_ARM  /* Disabled until runtime services implemented */
>> >> +
>> >> +#if defined(CONFIG_ARM_64) && defined(CONFIG_ACPI)
>> >> +const bool_t efi_enabled = 1;
>> >> +#else
>> >>   const bool_t efi_enabled = 0;
>> >> +#endif
>> >> +
>> > 
>> > Thinking a bit more about this variable. The usage of the variable is 
>> > unclear. Does it mean that Xen is supporting EFI runtime or Xen has been 
>> > boot with EFI?
>> 
>> The latter (it just so happens that it also means the former on x86
>> for the time being).
>> 
>> > The binary produced on ARM64 always is able to boot with and without 
>> > EFI. So it would seems logical to me that the value of this variable may 
>> > change at runtime.
>> 
>> Correct - other than (currently) on x86.
> 
> IOW it should become non-const on !x86? 

Yes. With Daniel's work it'll become non-const on x86 too at some
point.

> Does that also imply that some code which is using it to signal
> availability of Runtime Services should be switch to some other (new?)
> variable?

I hope not - we already have efi_rs_enable, and I would hope all
uses of runtime services are gated upon that. Of course turning
off efi_enabled may need to imply also clearing efi_rs_enable.

Jan


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