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
|
Home