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] mem_sharing: summarized problems when domain is dying

To: Jui-Hao Chiang <juihaochiang@xxxxxxxxx>
Subject: Re: [Xen-devel] mem_sharing: summarized problems when domain is dying
From: George Dunlap <dunlapg@xxxxxxxxx>
Date: Fri, 21 Jan 2011 16:29:56 +0000
Cc: MaoXiaoyun <tinnycloud@xxxxxxxxxxx>, xen devel <xen-devel@xxxxxxxxxxxxxxxxxxx>, Tim Deegan <Tim.Deegan@xxxxxxxxxx>
Delivery-date: Fri, 21 Jan 2011 08:31:49 -0800
Dkim-signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=VJHoEdvHPJvx9WrZn8rHV5dYFiEL8vsPp5bHDhLiZEI=; b=MAANlkgPyecqi3sH7OkwlbgFHq6Mwj2v3fNe7u+Matss1zkUVRH2igYRFmE8Yocs17 4DncE4IdhtqtVLcLM8E+cT+3ixpXJ+BFe68LITuspXdrksjx9LqmH3KCHQlHK7WdSHTV DazMU7VSzKYVgkDNwCtPtmxIysPOXQKagr9zA=
Domainkey-signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; b=u27tyrdCuG8nM+Pz3XGqJcNziGGgwOvA/NN/v4kMDtIM6P1Q89DjpuGCJrw7+QzQSB Vcj08Nzhm5tRgNOfRLDpD9ai+Q1suNB9g9y+Z6jxddXO/NZhmBw5swxLVFAjVL3hhrb8 yVcZbQiu+anJP5xch7VaP3z75dRceHaamn+qM=
Envelope-to: www-data@xxxxxxxxxxxxxxxxxxx
In-reply-to: <AANLkTi=wimfV7Wc6aEd2cYS-=dOb2V5Xy97eSCgW-gKh@xxxxxxxxxxxxxx>
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: <AANLkTi=wimfV7Wc6aEd2cYS-=dOb2V5Xy97eSCgW-gKh@xxxxxxxxxxxxxx>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
On Fri, Jan 21, 2011 at 4:19 PM, Jui-Hao Chiang <juihaochiang@xxxxxxxxx> wrote:
> (b) hap_nested_page_fault: if we return fail, will this cause problem
> to guest? or we can simply return success to cheat the guest. But
> later the guest will trigger another page fault if it write the page
> again.
> (c) gnttab_map_grant_ref: this function specify must_succeed to
> gfn_to_mfn_unshare(), which would BUG if unshare() fails.

I took a glance around the code this morning, but it seems like:

(b) should never happen.  If a domain is dying, all of its vcpus
should be offline.  If I'm wrong and there's a race between
d->is_dying set and the vcpus being paused, then the vcpus should just
be paused if they get an un-handleable page fault.

(c) happens because backend drivers may still be servicing requests
(finishing disk I/O, incoming network packets) before being torn down.
 It should be OK for those to fail if the domain is dying.

I'm not sure the exact rationale behind the "cannot fail" flag; but it
looks like in grant_table.c, both callers of gfn_to_mfn_unshare()
handle the case where the returned p2m entry is just

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