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

["Jan Beulich" <JBeulich@xxxxxxxx>]

>>> On 27.01.15 at 15:26, <konrad.wilk@xxxxxxxxxx> wrote:
> 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.

Again - apart from mapping the range, did you also make sure it
didn't get passed to the allocator (and hence couldn't have got
overwritten)?

Jan


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