[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 Xen-devel@xxxxxxxxxxxxx http://lists.xen.org/xen-devel
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |