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

[Daniel Kiper <daniel.kiper@xxxxxxxxxx>]

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, <konrad.wilk@xxxxxxxxxx> 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

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