From mboxrd@z Thu Jan 1 00:00:00 1970 From: "Jan Beulich" Subject: AW: Re: Xen BUG in mm / Xen 4.0.1 with 2.6.32.18/21 pvops Kernel? Date: Fri, 10 Sep 2010 09:48:33 +0100 Message-ID: <4C8A0D010200007800015611@vpn.id2.novell.com> References: <4C88CBAD02000078000152AD@vpn.id2.novell.com> Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: quoted-printable Return-path: In-Reply-To: Content-Disposition: inline List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com To: Carsten Schiers Cc: xen-devel List-Id: xen-devel@lists.xenproject.org >>> On 09.09.10 at 20:27, "Carsten Schiers" wrote: > and provided the output, just in case it is what you needed. I will = for=20 > sure need some time to understand that. > Is the hypothesis that a) the BIOS is wrong, and b) Xen is checking = more=20 > extreme than bare metal, so we need to > make the Xen Code a bit more relaxed (error message instead of crash)? I think the underlying problem was pointed out before: The page table accessor functions can't currently propagate errors, and hence ioremap() can't be forced to fail if Xen refused a mapping. And then, as I wrote in an earlier reply, the check for not trying to map RAM from ioremap() is pretty pointless (and hence no help) currently for the Xen case. Jan