Re: [Xen-devel] [PATCH v4 12/19] efi: introduce EFI_RS to ease control on runtime services usage

["Jan Beulich" <JBeulich@xxxxxxxx>]

>>> On 18.08.16 at 12:30, <daniel.kiper@xxxxxxxxxx> wrote:
> On Wed, Aug 17, 2016 at 10:12:32AM -0600, Jan Beulich wrote:
>> >>> On 06.08.16 at 01:04, <daniel.kiper@xxxxxxxxxx> wrote:
>>
>> Apart from the question of this probably better getting merged with
>> the previous patch ...
>>
>> > --- a/xen/common/efi/boot.c
>> > +++ b/xen/common/efi/boot.c
>> > @@ -936,6 +936,10 @@ efi_start(EFI_HANDLE ImageHandle, EFI_SYSTEM_TABLE 
> *SystemTable)
>> >
>> >      __set_bit(EFI_BOOT, &efi.flags);
>> >
>> > +#ifndef CONFIG_ARM /* Disabled until runtime services implemented. */
>> > +    __set_bit(EFI_RS, &efi.flags);
>> > +#endif
>>
>> ... this needs to be paralleled by a __clear_bit() when "efi=no-rs"
>> was given (and then efi_rs_enable) should go away. Oh, looks
>> like that's the next patch, but I'd then again question the split.
> 
> Do you suggest that patches 11-13 should be merged into one thing?
> If it is OK for you I can do that.
> 
>> > --- a/xen/include/xen/efi.h
>> > +++ b/xen/include/xen/efi.h
>> > @@ -12,6 +12,7 @@
>> >  struct efi {
>> >      unsigned long flags;        /* Bit fields representing available EFI 
> features/properties */
>> >  #define EFI_BOOT  0       /* Were we booted from EFI? */
>> > +#define EFI_RS            2       /* Can we use runtime services? */
>>
>> Why is this not the sequentially next number?
> 
> I wish that EFI_LOADER (added in patch 16) has number 1 (next to EFI_BOOT).

That'll then too end up more natural by merging the patches.

Jan


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