This is an archived copy of the Xen.org mailing list, which we have preserved to ensure that existing links to archives are not broken. The live archive, which contains the latest emails, can be found at http://lists.xen.org/
Home Products Support Community News


[Xen-devel] Re: [PATCH 3/8] xen/setup: Set identity mapping for non-RAM

To: Ian Campbell <Ian.Campbell@xxxxxxxxxxxxx>
Subject: [Xen-devel] Re: [PATCH 3/8] xen/setup: Set identity mapping for non-RAM E820 and E820 gaps.
From: Konrad Rzeszutek Wilk <konrad.wilk@xxxxxxxxxx>
Date: Tue, 4 Jan 2011 13:38:22 -0500
Cc: Jeremy Fitzhardinge <jeremy@xxxxxxxx>, "xen-devel@xxxxxxxxxxxxxxxxxxx" <xen-devel@xxxxxxxxxxxxxxxxxxx>, Stefano Stabellini <Stefano.Stabellini@xxxxxxxxxxxxx>, "linux-kernel@xxxxxxxxxxxxxxx" <linux-kernel@xxxxxxxxxxxxxxx>, Jan Beulich <JBeulich@xxxxxxxxxx>, Konrad Rzeszutek Wilk <konrad@xxxxxxxxxx>, "hpa@xxxxxxxxx" <hpa@xxxxxxxxx>
Delivery-date: Tue, 04 Jan 2011 10:40:31 -0800
Envelope-to: www-data@xxxxxxxxxxxxxxxxxxx
In-reply-to: <1294161538.3831.639.camel@xxxxxxxxxxxxxxxxxxxxxx>
List-help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-id: Xen developer discussion <xen-devel.lists.xensource.com>
List-post: <mailto:xen-devel@lists.xensource.com>
List-subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
List-unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
References: <1293738517-7287-1-git-send-email-konrad.wilk@xxxxxxxxxx> <1293738517-7287-4-git-send-email-konrad.wilk@xxxxxxxxxx> <1294161538.3831.639.camel@xxxxxxxxxxxxxxxxxxxxxx>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
User-agent: Mutt/1.5.20 (2009-06-14)
On Tue, Jan 04, 2011 at 05:18:58PM +0000, Ian Campbell wrote:
> On Thu, 2010-12-30 at 19:48 +0000, Konrad Rzeszutek Wilk wrote:
> > We walk the E820 region and start at 0 (for PV guests we start
> I was trying to figure out what any of this had to do with HVM guests,
> but you mean as opposed to dom0, which with my pedant hat on is also a
> guest ;-).
> >  and skip any E820 RAM regions. For all other
> > regions and as well the gaps we set them to be identity mappings.
> > 
> > The reasons we do not want to set the identity mapping from 0->
> > ISA_END_ADDRESS when running as PV is b/c that the kernel would
> > try to read DMI information and fail (no permissions to read that).
> The reason for this special case is that in domU we have already punched
> a hole from 640k-1M into the e820 which the hypervisor gave us.

For the privileged guest - yes. But for the non-priviligied it does not have
such range and would end up failing.
> Should we perhaps be doing this identity mapping before we punch that
> extra hole? i.e. setup ID mappings based on the hypervisors idea of the
> guest e820 not the munged one we subsequently magicked up? Only the

You mean the ISA_START_ADDRESS->ISA_END_ADDRESS we mark as reserved?

It sure would be easier (and it would mean we can return that memory
back to the hypervisor).

> original e820 is going to bear any possible resemblance to the identity
> pages which the guest can actually see.
> Ian.

Xen-devel mailing list