From mboxrd@z Thu Jan  1 00:00:00 1970
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Subject: Re: fyi, Xen's EFI workarounds (/mapbs & efi=no-rs) on
 SuperMicro hardware;
 fixes solve 1/2 problems & SM responds that can't/won't fix their firmware
Date: Mon, 7 Dec 2015 13:09:00 -0500
Message-ID: <20151207180900.GD23105@char.us.oracle.com>
References: <56621EBF.2000301@gmail.com>
	<20151205180537.GA8112@char.us.oracle.com>
	<56632DB7.1090503@gmail.com>
	<D5376F95-4672-4FDD-A951-5194B8537D4C@oracle.com>
	<56634F20.5090801@gmail.com>
	<20151207142012.GB22814@char.us.oracle.com>
	<20151207142050.GA24671@char.us.oracle.com>
	<5665BECA.6030605@cardoe.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Return-path: <xen-devel-bounces@lists.xen.org>
Content-Disposition: inline
In-Reply-To: <5665BECA.6030605@cardoe.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: Doug Goldstein <cardoe@cardoe.com>
Cc: xen-devel@lists.xen.org
List-Id: xen-devel@lists.xenproject.org

> > Now attached.
> >>
> >> xen.efi /noexitboot /mapbs
> >>
> >> And you can try without 'efi=no-rs'.
> >>
> >> However I am wondering - why are you using '/mapbs' ? What did it
> >> help? (The combination of 'efi=no-rs' means you are in effect not
> >> using _any_ EFI operations - so doing /mapbs is not needed).
> >>
> >>
> >> _______________________________________________
> >> Xen-devel mailing list
> >> Xen-devel@lists.xen.org
> >> http://lists.xen.org/xen-devel
> 
> Konrad,

Heya!!
> 
> Can we land the /noexitboot (probably better to call it /noexitbs to
> match rs) into the tree?

It is up to the EFI maintainer (Jan) who would like the vendors to
fix their broken firmware before adding this gross hack in.

> 
> I have to have a very similar patch locally to bring up my machine and
> it would make sense that if you and I are seeing this problem then
> others are.

I think the way going forward is to make Xen capable of working in the
VirtualAddress instead of the 1:1. The problem isn't fixing the code
(it blows up if you try enabling) - it is that we lose kexec support
unless we also make kexec be less Linux-centric when booting under EFI.

This is a topic I think we should bring up at the XenHackathon(Dev summit?)
in Cambridge, UK to hash out.