WARNING - OLD ARCHIVES

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/
   
 
 
Xen 
 
Home Products Support Community News
 
   
 

xen-devel

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

To: Tim Deegan <tim@xxxxxxx>, Olaf Hering <olaf@xxxxxxxxx>, Adin Scannell <adin@xxxxxxxxxxxxxx>
Subject: Re: [Xen-devel] Re: mapping problems in xenpaging
From: zhen shi <bickys1986@xxxxxxxxx>
Date: Mon, 10 Oct 2011 00:40:32 +0800
Cc: xen-devel@xxxxxxxxxxxxxxxxxxx
Delivery-date: Sun, 09 Oct 2011 09:41:09 -0700
Dkim-signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=qelL55PDfVlY9OwfV4On8CaP8qyMHQS1EJD2Tuj/Y+8=; b=fcPfmTHYZZU0SzA3YkZVrDK+tmc8fHMQ9zDmyl9A+7VUnPpHDF98WPhR4S4qaML7rJ wz2v2SUzcWznUe5Sq0osfD8gxar8ySQv8ZgkFgK2nZUVErROyBNg1IR66E0zvwBXkx+H YK+yoeNR+HPzikQKfWjPmxdeE8bOKHQWBP4dw=
Envelope-to: www-data@xxxxxxxxxxxxxxxxxxx
In-reply-to: <20111006111044.GD21091@xxxxxxxxxxxxxxxxxxxxx>
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: <CACavRyB4kvMLZK1-vv9bJnVdnpKJBHTmnhJxt6g3eh88xY6FTg@xxxxxxxxxxxxxx> <20110929170244.GA29163@xxxxxxxxx> <CAAJKtqrFuJkNAZZhRs8tC0ymgQTD0G2VTgYexQ9EhnCxsJNZuw@xxxxxxxxxxxxxx> <20111003145616.GA8610@xxxxxxxxx> <20111006111044.GD21091@xxxxxxxxxxxxxxxxxxxxx>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx

2011/10/6 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;

    I wonder if pages have been mapped by other domains,then the page->count_info will be added.I have analyzed  xc_map_foreign_pages() function,and have not figured out how to add the page->count_info by xc_map_foreign_pages().and the page->count_info decreases in munmap().
 
> > *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 , Olaf and Adin, do you have any good ideas about the above situation. 

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel
<Prev in Thread] Current Thread [Next in Thread>