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

[Konrad Rzeszutek Wilk <konrad.wilk@xxxxxxxxxx>]

On Thu, Jan 29, 2015 at 10:35:08AM +0000, Jan Beulich wrote:
> >>> On 28.01.15 at 18:20, <konrad.wilk@xxxxxxxxxx> wrote:
> > On Wed, Jan 28, 2015 at 04:56:02PM +0000, Jan Beulich wrote:
> >> >>> On 28.01.15 at 17:17, <daniel.kiper@xxxxxxxxxx> 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@xxxxxxxxxx>
> > 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@xxxxxxxxxx>
> > Date:   Fri Dec 20 18:02:20 2013 +0800
> > 
> >     x86: Add xloadflags bit for EFI runtime support on kexec
> 
> Compare the dates of these with that of the Xen commit(s) enabling
> EFI support. Plus - this protocol is absolutely Linux-centric afaict,
> whereas Xen's kexec interface/support should be as generic as
> possible.

<blinks> kexec is OS agnostic? I must have missed that. Either way
these two commits are something that the Xen kexec maintainer
should probably know about (CCing him).
> 
> > ..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?
> 
> Not sure what that would be good for: The commented out code is
> there just for documentation purposes. It was never expected that
> you could simply enable it and expect it to work (albeit I _very_
> vaguely recall it having worked very early on during development of
> the EFI support code).

Aaah, so dead code.
> 
> Considering how broken the EFI appears to be on that laptop, why
> don't you simply turn it off (just like is required on many other
> systems with too early versions of it - reportedly in some cases
> turning it on renders systems un-bootable, with it being very difficult
> to turn it back off; I'm supposedly even in possession of such a
> system, but guess what - I don't want to try it out).

Haha!
> 
> Jan
> 

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