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

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

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@xxxxxxxxxx> 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@xxxxxxxxxx> 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
> the efi-rs workaround option - we should deprecate that one, and
> have a consolidated efi= one instead, covering the case here too.
> 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
> problems with the conversion of the EFI memory map to E820 form,
> both because of the number of entries needed, and because that
> conversion happens _before_ the normal command line parsing.

Twisty maze. 

However even with my 'debug' patch and mapping the boot services
it still fails on this laptop. So I fear there is something more
to my woes with Lenovo's EFI firmware implementation.
> Jan

Xen-devel mailing list



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