From mboxrd@z Thu Jan 1 00:00:00 1970 From: Daniel Kiper Subject: Re: EFI GetNextVariableName crashes when running under Xen, but not under Linux. efi-rs=0 works. No memmap issues Date: Wed, 28 Jan 2015 17:17:44 +0100 Message-ID: <20150128161744.GB3473@olila.local.net-space.pl> 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> <20150127142605.GA8814@l.oracle.com> <54C7C8110200007800059EE4@mail.emea.novell.com> <20150127182028.GB3678@x230.dumpdata.com> <54C8AE9C020000780005A31D@mail.emea.novell.com> <20150128160319.GB3923@l.oracle.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: Received: from mail6.bemta4.messagelabs.com ([85.158.143.247]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1YGVJX-0007BJ-SI for xen-devel@lists.xenproject.org; Wed, 28 Jan 2015 16:18:00 +0000 Content-Disposition: inline In-Reply-To: <20150128160319.GB3923@l.oracle.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: Konrad Rzeszutek Wilk Cc: Andrew Cooper , Jan Beulich , xen-devel List-Id: xen-devel@lists.xenproject.org On Wed, Jan 28, 2015 at 11:03:19AM -0500, Konrad Rzeszutek Wilk wrote: > On Wed, Jan 28, 2015 at 08:40:44AM +0000, Jan Beulich wrote: > > >>> On 27.01.15 at 19:20, wrote: > > > On Tue, Jan 27, 2015 at 04:17:05PM +0000, Jan Beulich wrote: > > >> 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)? > > > > > > Yes, see patch: > > > > Oh, sorry, I must have not looked closely enough. > > > > > Also see attached of the code with what Linux sees and what Xen sees > > > (Linux first). > > > > Indeed this > > > > 8b: 44 38 2d c2 10 00 00 cmp %r13b,0x10c2(%rip) # 0x115 [01 01 00 00 00 00 00 00][00 01 00 00 00 00 00 00 > > 92: 75 12 jne 0xa6 > > > > causes the code in question to be skipped under Linux. > > > > > I am thinking that the firmware is under the assumption > > > that if SetVirtualAddressMap is not called then you MUST be still > > > before ExitBootServices has been called. Going to verify that by > > > implementing an GetNextVariableName before calling ExitBootServices) > > > > Not sure how exactly you envision to do this, but I'm having a hard > > time seeing how this would prove anything, in particular because > > calling runtime services functions prior to exiting boot services must > > be possible anyway. > > And it works - one of the patches implements an routine to call the > dreaded function before ExitBootServices and it works nicely (ie - I > see: > > Xen 4.6-unstable (c/s Tue Jan 27 14:05:36 2015 -0500 git:332c049-dirty) EFI loader > Using configuration file 'xen.cfg' > vmlinuz-3.19.0-rc4+: 0x00000000cf81a000-0x00000000cfda5f90 > initramfs-3.19.0-rc4+.img: 0x00000000cb522000-0x00000000cd7b04d3 > GetNextVariableName: > 0x8be4df610x93ca0x11d20xaa0xd0x00xe00x980x30x2b0x8c:SimpleBootFlag 0x0 > 0x5e724c0c0x5c030x45430xbc0xb60xc10xe20x3d0xe20x410x36:TpmSaveState 0x0 > 0x6403753b0xabde0x4da20xaa0x110x690x830xef0x2a0x7a0x69:TpmAcpiData 0x0 > 0x8be4df610x93ca0x11d20xaa0xd0x00xe00x980x30x2b0x8c:SetupMode 0x0 > 0x8be4df610x93ca0x11d20xaa0xd0x00xe00x980x30x2b0x8c:SecureBoot 0x0 > 0xe5bbf7be0x24170x499b0x970xdb0x390xf40x890x630x910xbc:BuildDate 0x0 > Could not get next variable > > > It is just that making that call after ExitBootServices does not > work. But on Linux the extra mix is that we also call 'SetVirtualAddressMap' > which we do not do. > > > > And iirc you had already tried calling the function prior to doing much > > else (namely, prior to loading Dom0), and it still crashed? Did you > > Yes, it did crash. That is - we call it _after_ calling ExitBootServices. > > > investigate when the memory type of that region changes (in an > > earlier mail you said dmem from the EFI shell reported it as Boot > > Services, albeit it's not fully clear what that tagging is supposed to > > be telling us)? > > It did not help. Having the mapping of BootServicesData&Code did not > help with the problem. However having disabled the call to > ExitBootServices the mapping of BootServicesData&Code did help - as we > were able to make the proper calls. > > In short, I think the firmware has a bug where it makes the assumption > that if SetVirtualAddressMap then BootServices should _not_ be used > - otherwise it will use it. > > I am not really sure of what the work-around should be in Xen except > making SetVirtualAddressMap work.. Hmmm... Crazy idea. IIRC, we use RS in 1:1 mapping. If we need to call SetVirtualAddressMap() then force it to create 1:1 mapping. Is it possible? Could you try it? I think you should play with code just before SetVirtualAddressMap(). Daniel