Re: audit_p2m errors, p2m_mmio_direct turns into p2m_ram_logdirty

[Olaf Hering <olaf@aepfle.de>]

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.

Olaf