From mboxrd@z Thu Jan 1 00:00:00 1970 From: Konrad Rzeszutek Wilk Subject: Re: EFI GetNextVariableName crashes when running under Xen, but not under Linux. efi-rs=0 works. No memmap issues Date: Tue, 27 Jan 2015 09:26:05 -0500 Message-ID: <20150127142605.GA8814@l.oracle.com> References: <20150126162753.GA1812@l.oracle.com> <54C680C90200007800059907@mail.emea.novell.com> <20150127000247.GU3473@olila.local.net-space.pl> <54C6DCB7.3060206@citrix.com> <54C752460200007800059B8B@mail.emea.novell.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: Received: from mail6.bemta5.messagelabs.com ([195.245.231.135]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1YG75s-0004X9-AV for xen-devel@lists.xenproject.org; Tue, 27 Jan 2015 14:26:16 +0000 Content-Disposition: inline In-Reply-To: <54C752460200007800059B8B@mail.emea.novell.com> List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org To: Jan Beulich Cc: Andrew Cooper , Daniel Kiper , xen-devel List-Id: xen-devel@lists.xenproject.org On Tue, Jan 27, 2015 at 07:54:30AM +0000, Jan Beulich wrote: > (re-adding xen-devel) > > >>> On 27.01.15 at 01:32, 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, 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 >