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


Re: [Xen-devel] audit_p2m errors, p2m_mmio_direct turns into p2m_ram_log

To: Tim Deegan <Tim.Deegan@xxxxxxxxxx>
Subject: Re: [Xen-devel] audit_p2m errors, p2m_mmio_direct turns into p2m_ram_logdirty
From: Olaf Hering <olaf@xxxxxxxxx>
Date: Wed, 3 Nov 2010 14:59:22 +0100
Cc: "xen-devel@xxxxxxxxxxxxxxxxxxx" <xen-devel@xxxxxxxxxxxxxxxxxxx>
Delivery-date: Wed, 03 Nov 2010 07:00:30 -0700
Dkim-signature: v=1; a=rsa-sha1; c=relaxed/relaxed; t=1288792765; l=1438; s=domk; d=aepfle.de; h=In-Reply-To:Content-Type:MIME-Version:References:Subject:Cc:To:From: Date:X-RZG-CLASS-ID:X-RZG-AUTH; bh=waT5eVxvN/DfL1zL2sHfN/ePbaw=; b=pu+pdp6/t3oVpm+hTISDjyJ3UyBKpQ/6s3Uw+dU2i8K5ev69r9vc5BwY26McET7hj/H 0MeuOMc5FsUsL5gYETrtzemtxO5JWNUSGlo0a0DN9cAPJXa6fZ76liu87qialDppEbBUt GxVLmclFLRv7uA6UkyERuXs6NfFwPh7kcE4=
Envelope-to: www-data@xxxxxxxxxxxxxxxxxxx
In-reply-to: <20101103121222.GF11016@xxxxxxxxxxxxxxxxxxxxxxx>
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: <20101102165429.GA30730@xxxxxxxxx> <20101103121222.GF11016@xxxxxxxxxxxxxxxxxxxxxxx>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
User-agent: Mutt/1.5.20 (2009-06-14)
On Wed, Nov 03, Tim Deegan wrote:

> > Today I tried it again in the hope to get some help for xenpaging
> > debugging in xen-4.0, but it ran into a BUG right away.
> > For some reason the p2m type set by set_mmio_p2m_entry for gfn 0xfee00
> > is 2 instead of 5 when audit_p2m checks it.
> I wans't able to reproduce this on xen-unstable tip.  Were you using the
> paging code at the time?

Its with the 4.0 tree, and xenpaging starts much later. Its the early
domain setup code.

> > (XEN) p2m: audit_p2m(1839): OK: mfn=0x133b86, gfn=0xed47f, 
> > p2mfn=0xffffffffffffffff, lp2mfn=0x0
> > (XEN) p2m: audit_p2m(1941): mismatch: gfn 0xfee00 -> mfn 0x134012 -> gfn 
> > 0xffffffffffffffff (p2mt 2)
> That's a bug, though. 
> Your line numbers don't match my tree, but I take it this is the third
> (i.e. non-superpage) instance of this check?  In that case it looks like
> it's found a real bug - for any log-dirty RAM p2m entry the m2p ought to
> match the p2m.  Also an MMIO entry shouldn't become without becoming
> normal RAM in the meantime. 
> The next step, I'm afraid, is to trace where the type is getting
> changed.  If the pfn is the same on each run (and it look like it should
> be) then you should be able to put an appropriate WARN_ON in
> paging_write_p2m_entry() to catch all changes to that pfn's type.

Thanks for looking into this. I will try to trace this and see where the
type changes.


Xen-devel mailing list

<Prev in Thread] Current Thread [Next in Thread>