Re: EFI GetNextVariableName crashes when running under Xen, but not under Linux. efi-rs=0 works. No memmap issues

[Daniel Kiper <daniel.kiper@oracle.com>]

On Tue, Jan 27, 2015 at 07:54:30AM +0000, Jan Beulich wrote:
> (re-adding xen-devel)
>
> >>> On 27.01.15 at 01:32, <andrew.cooper3@citrix.com> wrote:
> > On 27/01/2015 00:02, Daniel Kiper wrote:
> >> On Mon, Jan 26, 2015 at 05:00:41PM +0000, Jan Beulich wrote:
> >>>>>> On 26.01.15 at 17:27, <konrad.wilk@oracle.com> wrote:
> >>>> Anyhow I am bit stuck:
> >>>>  1) It works with Linux, so what is it that Linux does that
> >>>>     Xen does not?
> >>> They map more than just what is marked for runtime use.
> >> IIRC, Linux maps boot services unconditionally (and states in comment
> >> that this is not in line with spec). We do not have such mechanism.
> >> Could we ease life of our users and add a boot option (e.g. map-efi-bs)
> >> which will enforce mapping of BS regions on platforms with buggy EFI/UEFI
> >> implementations? We should not penalize owners of such hardware because
> >> they are not guilty of these crazy bugs. We should educate firmware devs...
> >> Ehh... Please, do not curse at me. I remember discussion about EFI reset
> >> stuff which happened here a few days ago.
> >
> > While, in principle, I would like to take a tough stand against buggy
> > firmware, the truth is that firmware is always going to be buggy, and
> > many users are going to be in a position where their buggy firmware is
> > not going to be fixed by their vendors.  Much as I would prefer not to,
> > I feel that the only rational course of action to take is to behave like
> > Linux in cases like this.
> >
> > Therefore, I am a begrudgingly +1 "work around EFI firmware bugs",
> > despite it being the wrong pragmatic thing to do.
>
> And I agree that we will need to accept in such workarounds. But
> two remarks to whoever is going to implement it: We already have

I will add this to my TODO list and I will do it with current EFI
work (I am going to post it shortly after fixing two issues).

> the efi-rs workaround option - we should deprecate that one, and
> have a consolidated efi= one instead, covering the case here too.

OK.

> Plus the issue here is not just a matter of mapping BS memory, but
> also not making it available to the allocator. That in turn may yield

Yep, however, I thought that if a memory region is reserved in E820
then it is also automatically removed from allocator pool.

> problems with the conversion of the EFI memory map to E820 form,
> both because of the number of entries needed, and because that

In worst case we can try to allocate E820 map dynamically
or ignore this option completely if new map do not fit in
statically allocated E820 memory map region.

> conversion happens _before_ the normal command line parsing.

I am going to align EFI early command line parser to legacy
BIOS early boot path parser (I think about vga command line
option). So, I think that this EFI "bug" work could be based
on it.

Daniel