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 6/8] xen/debug: WARN_ON when 1-1 but no _PAGE_IOM

To: Ian Campbell <Ian.Campbell@xxxxxxxxxxxxx>
Subject: [Xen-devel] Re: [PATCH 6/8] xen/debug: WARN_ON when 1-1 but no _PAGE_IOMAP flag set.
From: Stefano Stabellini <stefano.stabellini@xxxxxxxxxxxxx>
Date: Thu, 6 Jan 2011 19:50:26 +0000
Cc: Fitzhardinge <jeremy@xxxxxxxx>, "xen-devel@xxxxxxxxxxxxxxxxxxx" <xen-devel@xxxxxxxxxxxxxxxxxxx>, Jeremy, Konrad Rzeszutek Wilk <konrad.wilk@xxxxxxxxxx>, Stefano Stabellini <Stefano.Stabellini@xxxxxxxxxxxxx>, "linux-kernel@xxxxxxxxxxxxxxx" <linux-kernel@xxxxxxxxxxxxxxx>, Jan Beulich <JBeulich@xxxxxxxxxx>, Konrad Rzeszutek Wilk <konrad@xxxxxxxxxx>, "hpa@xxxxxxxxx" <hpa@xxxxxxxxx>, Keir Fraser <keir@xxxxxxx>
Delivery-date: Thu, 06 Jan 2011 11:49:54 -0800
Envelope-to: www-data@xxxxxxxxxxxxxxxxxxx
In-reply-to: <1294168856.3582.16.camel@xxxxxxxxxxxxxxxxxxxxx>
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-7-git-send-email-konrad.wilk@xxxxxxxxxx> <1294161878.3831.654.camel@xxxxxxxxxxxxxxxxxxxxxx> <20110104184604.GB1505@xxxxxxxxxxxx> <1294168856.3582.16.camel@xxxxxxxxxxxxxxxxxxxxx>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
User-agent: Alpine 2.00 (DEB 1167 2008-08-23)
On Tue, 4 Jan 2011, Ian Campbell wrote:
> On Tue, 2011-01-04 at 18:46 +0000, Konrad Rzeszutek Wilk wrote: 
> > On Tue, Jan 04, 2011 at 05:24:38PM +0000, Ian Campbell wrote:
> > > On Thu, 2010-12-30 at 19:48 +0000, Konrad Rzeszutek Wilk wrote:
> > > > Only enabled if XEN_DEBUG_FS is enabled.
> > > 
> > > Bit of an odd configuration option to use. Perhaps co-opt
> > > 
> > > Or maybe we need a new XEN_DEBUG option? or just make it a developer
> > > only EXTRA_CFLAGS +=-DDEBUG thing?
> > 
> > I think the 'XEN_DEBUG' works better.
> > > 
> > > Is this only temporary until the need for _PAGE_IOMAP is removed anyway?
> > 
> > I was thinking to leave it as a way to weed out bugs, but I could as well
> > just leave it in my "debug" branch and not propose it upstream.
> > 
> > I am not sure how to remove the _PAGE_IOMAP fully. We need some _flag_ to
> > signal 'xen_pte_val' that the PTE should not be looked up in the M2P.
> > 
> > Otherwise, for identity mappings, the value is 0xfffff.. (or 0x55555.. 
> > sometimes)
> > and the PTE ends up being messed up. Instead there is a check to see if
> > _PAGE_IOMAP is part of the PTE, and if so, no M2P lookup is done.
> > 
> > I guess we could do the M2P irregardless and just see if it is 0xfffff... 
> > and
> > if so just return the PTE without any changes.
> Perhaps this ties in with the m2p overlay which Stefano+Jeremy have been
> working on to deal with granted foreign pages? I/O pages are a bit like
> foreign memory (if you squint enough)...
In theory the m2p overlay could be used for this purpose but in practice
the current m2p overlay API needs a struct page, also it might end up
stressing the hashtable too much.

Besides I think Konrad's solution might be simpler: if the m2p returns
one of the two special values we just return mfn from pte_mfn_to_pfn.

Keir, could you confirm that the m2p entries of DOM_IO pages are always
0xffffff or 0x55555?

Xen-devel mailing list