From mboxrd@z Thu Jan 1 00:00:00 1970 From: "Jiang, Yunhong" Subject: RE: Re: [PATCH] Support swap a page from user spacetools -- Was RE: [RFC][PATCH] Basic support for page offline Date: Fri, 20 Mar 2009 18:36:52 +0800 Message-ID: References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Return-path: In-Reply-To: Content-Language: en-US List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com To: Keir Fraser , Jan Beulich Cc: Tim Deegan , "xen-devel@lists.xensource.com" List-Id: xen-devel@lists.xenproject.org Keir Fraser wrote: > On 20/03/2009 10:13, "Jiang, Yunhong" wrote: >=20 >>> Even this may not work. Old grants will reference the old page. Subsequ= ent >>> attempts by a backend to map the grant will fail. And the resulting fai= led >>> I/Os will probably make the frontend driver throw a fit. Getting this >>> working with suspend-cancel seems pretty tricky. >>=20 >> If there is grant map for it, I think we will fail since the reference i= s >> not 1 when XENMEM_exchange.=20 >>=20 >> Or do you mean there is a reference in grant table but is not mapped sti= ll? >> Will the refrence count be added when a page is granted? I'm not quite s= ure >> about this, but I think that will be same to original XENMEM_exchange. I= f >> yes, we may have to update the grant information? >=20 > Reference counts are not adjusted until a grant is mapped. So > I'm talking > about grants which have been written by the domU, passed to the backend > driver, but not yet used. Those will be screwed. Got it.=20 >=20 > Anyway, see my email just now, which suggests you map the guest's grant > table into your toolstack code, and you can go check for > existing grants > yourself. As I say there -- if you do that I don't think you need worry > about atomicity of the copy.=20 Are there any method for user space to get the grant table information? >=20 > -- Keir=