From mboxrd@z Thu Jan  1 00:00:00 1970
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Subject: Is: kexec & EFI Was: Re: EFI GetNextVariableName
 crashes when running under Xen,
 but not under Linux. efi-rs=0 works. No memmap issues
Date: Fri, 30 Jan 2015 09:17:27 -0500
Message-ID: <20150130141727.GC4506@l.oracle.com>
References: <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>
	<20150128161744.GB3473@olila.local.net-space.pl>
	<54C922B2020000780005A79A@mail.emea.novell.com>
	<20150128172045.GB7189@l.oracle.com>
	<54CA1AEC020000780005AAD0@mail.emea.novell.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Return-path: <xen-devel-bounces@lists.xen.org>
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <konrad.wilk@oracle.com>) id 1YHCO8-000079-KO
	for xen-devel@lists.xenproject.org; Fri, 30 Jan 2015 14:17:36 +0000
Content-Disposition: inline
In-Reply-To: <54CA1AEC020000780005AAD0@mail.emea.novell.com>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org
To: Jan Beulich <JBeulich@suse.com>, david.vrabel@citrix.com
Cc: Andrew Cooper <andrew.cooper3@citrix.com>, Daniel Kiper <daniel.kiper@oracle.com>, xen-devel <xen-devel@lists.xenproject.org>
List-Id: xen-devel@lists.xenproject.org

On Thu, Jan 29, 2015 at 10:35:08AM +0000, Jan Beulich wrote:
> >>> On 28.01.15 at 18:20, <konrad.wilk@oracle.com> wrote:
> > 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
> 
> 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
>