Re: [Xen-ia64-devel] steal_page(MEMF_no_refcount) page->count_info no longer consistent

[Isaku Yamahata <yamahata@xxxxxxxxxxxxx>]

On Thu, Mar 01, 2007 at 11:59:27AM +0900, Isaku Yamahata wrote:
> On Wed, Feb 28, 2007 at 04:55:27PM -0700, Alex Williamson wrote:
> 
> >    Current xen-unstable.hg tip has a problem booting dom0 that I'd like
> > your opinion on.  We're failing the check in steal_page() that ensures
> > that count_info is 2 when called with the MEMF_no_refcount flag.  In
> > fact, it seems that steal_page() is now getting called for pages that
> > have a count_info of 1 or 2.  Are we being overly paranoid with this
> > check, or is this an indication of a deeper problem?  The change seems
> > to have been introduced by the recent memory allocator changes which
> > removed the bit width restrictions.  Thanks,
> 
> By the coarse code check, I couldn't find the case that count_info = 1
> with MEMF_no_refcount can occur.
> The reference count semantics seems to have been changed in a subtle way.
> I'll try to reproduce it and take a deeper look into it.

I found the root cause.
In fact XENMEM_exchange(memory_exchange()) has been broken on ia64.
Especially when memory_exchange() failed, page->count_info
is left in broken state (= PGC_allocated | 1).
The next time XENMEM_exchange hypercall is called, the message is printed out.
Probably we have to revise memory_exchange() in common code and
convince x86 developers.

So the temporal work around might be necessary.
The trigger is c/s 13366:ed73ff8440d8 in xen-unstable.hg.
swiotlb_init_with_default_size() was changed to pass
dma address bits which causes XENMEM_exchange fail.
The easy temporal work around is to modify swiotlb_init_with_default_size().
-- 
yamahata

_______________________________________________
Xen-ia64-devel mailing list
Xen-ia64-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-ia64-devel