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: Keir Fraser <keir@xxxxxxx>
Subject: [Xen-devel] Re: [PATCH 6/8] xen/debug: WARN_ON when 1-1 but no _PAGE_IOMAP flag set.
From: Konrad Rzeszutek Wilk <konrad.wilk@xxxxxxxxxx>
Date: Thu, 6 Jan 2011 16:59:52 -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>, Ian Campbell <Ian.Campbell@xxxxxxxxxxxxx>, Konrad Rzeszutek Wilk <konrad@xxxxxxxxxx>, "hpa@xxxxxxxxx" <hpa@xxxxxxxxx>
Delivery-date: Thu, 06 Jan 2011 14:02:50 -0800
Envelope-to: www-data@xxxxxxxxxxxxxxxxxxx
In-reply-to: <C94BD3E2.11441%keir@xxxxxxx>
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: <alpine.DEB.2.00.1101061935070.2390@kaball-desktop> <C94BD3E2.11441%keir@xxxxxxx>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
User-agent: Mutt/1.5.20 (2009-06-14)
On Thu, Jan 06, 2011 at 08:17:38PM +0000, Keir Fraser wrote:
> On 06/01/2011 19:50, "Stefano Stabellini" <stefano.stabellini@xxxxxxxxxxxxx>
> wrote:
> >> 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?
> Always 0x55...55 (for m2p entries that exist), else page fault on access to
> the non-existent m2p entry (m2p entries only guaranteed to exist for ram).
> Perhaps the 0xff...ff values come from Linux's own fixup code handling a
> faulting read access of the m2p array? If so you could return 0x55...55
> instead and avoid checking for 0xff...ff. I really don't know how you could
> get 0xff...ff for non-RAM pages from Xen itself.

The non-RAM pages are assinged to a DOMID_IO (arch_init_memory), for example:

 298     /* First 1MB of RAM is historically marked as I/O. */
 299     for ( i = 0; i < 0x100; i++ )
 300         share_xen_page_with_guest(mfn_to_page(i), dom_io, 

and share_xen_page.. sets that page to INVALID_M2P_ENTRY.

But I could also be reading the code wrongly?

>  -- Keir

Xen-devel mailing list