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

[Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>]

On Wed, Jan 28, 2015 at 04:56:02PM +0000, Jan Beulich wrote:
> >>> On 28.01.15 at 17:17, <daniel.kiper@oracle.com> wrote:
> > On Wed, Jan 28, 2015 at 11:03:19AM -0500, Konrad Rzeszutek Wilk wrote:
> >> 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().
> 
> Of course this is possible. The reason we don't call the function is
> kexec: How would the secondary kernel be able to make runtime
> calls if we already established some mapping? Remember that
> SetVirtualAddressMap() may not be called more than once...

Linux does seem to have the code to deal with this, via bootparams.
See git  1fec0533693cd74f2d1a46edd29449cfee429df0
Author: Dave Young <dyoung@redhat.com>
Date:   Fri Dec 20 18:02:19 2013 +0800

    x86/efi: Pass necessary EFI data for kexec via setup_data

456a29ddada79198c5965300e04103c40c481f62
Author: Dave Young <dyoung@redhat.com>
Date:   Fri Dec 20 18:02:20 2013 +0800

    x86: Add xloadflags bit for EFI runtime support on kexec


Which do:

"    When entering virtual mode, directly mapping the EFI runtime regions
    which we passed in previously. And skip the step to call
    SetVirtualAddressMap().
"

..that could be employed. The problem I had was that I tried to employ
SetVirtualAddressMap in the Xen code - but it did not work at all.

Jan, do you want me to send you an serial log with a Xen code with
SetVirtualAddressMap executed  -on a non-Lenovo machine to eliminate
the firmware issues?

> 
> Jan
>