Re: [Xen-devel] Re: mapping problems in xenpaging

[Tim Deegan <tim@xxxxxxx>]

At 16:56 +0200 on 03 Oct (1317660976), Olaf Hering wrote:
> On Fri, Sep 30, Adin Scannell wrote:
> 
> > >>  When we analyze and test xenpaging,we found there are some 
> > >> problems between
> > >> mapping and xenpaging.
> > >>  1) When mapping firstly, then do xenpaging,and the code paths have 
> > >> resolved
> > >> the problems.It's OK.
> > >>  2) The problems exists if we do address mapping firstly then go to
> > >> xenpaging,and our confusions are as followings:
> > >>    a) If the domU's memory is directly mapped to dom0,such as the 
> > >> hypercall
> > >> from pv driver,then it will build a related page-table in dom0,which 
> > >> will not
> > >> change p2m-type.
> > >>       and then do the xenpaging to page out the domU's memory pages 
> > >> whose gfn
> > >> address have been already mapped to dom0;So it will cause some problems 
> > >> when
> > >> dom0
> > >>       accesses these pages.Because these pages are paged-out,and dom0 
> > >> cannot
> > >> tell the p2mt before access the pages.
> > >
> > > I'm not entirely sure what you do. xenpaging runs in dom0 and is able to
> > > map paged-out pages. It uses that to trigger a page-in, see
> > > tools/xenpaging/pagein.c in xen-unstable.hg
> > 
> > Here's my take...
> > 
> > Xenpaging doesn't allow selection of pages that have been mapped by
> > other domains (as in p2m.c):
> > 
> >  669 int p2m_mem_paging_nominate(struct domain *d, unsigned long gfn)
> > ....
> >  693     /* Check page count and type */
> >  694     page = mfn_to_page(mfn);
> >  695     if ( (page->count_info & (PGC_count_mask | PGC_allocated)) !=
> >  696          (1 | PGC_allocated) )
> >  697         goto out;
> > 
> > *However*, I think that the problem Zhen is describing still exists:
> > 1) xenpaging nominates a page, it is successful.
> > 2) dom0 maps the same page (a process other than xenpaging, which will
> > also map it).
> > 3) xenpaging evicts the page, successfully.
> > 
> > I've experienced a few nasty crashes, and I think this could account
> > for a couple (but certainly not all)... I think that the solution may
> > be to repeat the refcount check in paging_evict, and roll back the
> > nomination gracefully if the race is detected. Thoughts?
> 
> Are there really code paths that touch a mfn without going through the
> p2m functions? If so I will copy the check and update xenpaging.

No, but there are race conditions where CPU A could to the p2m lookup,
then CPU B nominates the page and changes its p2m entry, then CPU A
completes the mapping.  In the extreme case, detecting this in the
eviction code is also subject to the same race; some sort of atomic
lookup-and-get-reference operation seems like a better fix.

Tim.

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