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] Some question to changeset 17962

To: Brendan Cully <brendan@xxxxxxxxx>, Keir Fraser <keir.fraser@xxxxxxxxxxxxx>
Subject: RE: [Xen-devel] Some question to changeset 17962
From: "Jiang, Yunhong" <yunhong.jiang@xxxxxxxxx>
Date: Tue, 10 Mar 2009 09:47:34 +0800
Accept-language: en-US
Acceptlanguage: en-US
Cc: "xen-devel@xxxxxxxxxxxxxxxxxxx" <xen-devel@xxxxxxxxxxxxxxxxxxx>
Delivery-date: Mon, 09 Mar 2009 18:48:24 -0700
Envelope-to: www-data@xxxxxxxxxxxxxxxxxxx
In-reply-to: <20090309163308.GB5883@xxxxxxxxxxxxxxxxxxx>
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: <E2263E4A5B2284449EEBD0AAB751098401C7D2A853@xxxxxxxxxxxxxxxxxxxxxxxxxxxx> <C5DA9592.4809%keir.fraser@xxxxxxxxxxxxx> <20090309163308.GB5883@xxxxxxxxxxxxxxxxxxx>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
Thread-index: Acmg1MDfFQfGpyr6QpGejA4FFc2nQQAS+RgA
Thread-topic: [Xen-devel] Some question to changeset 17962
Brendan Cully <mailto:brendan@xxxxxxxxx> wrote:
> On Monday, 09 March 2009 at 09:44, Keir Fraser wrote:
>> On 09/03/2009 09:25, "Jiang, Yunhong"
> <yunhong.jiang@xxxxxxxxx> wrote:
>> 
>>>> For (b), Xen itself has okay semantics -- the most recent caller to set
>>>> the suspend_evtchn always wins. How tools make use of that policy is up
>>>> to them works out fine.
>>> 
>>> Are there any special reason that not the first caller hold it (which is
>>> more nature IMO), and the later caller will failed?
>> 
>> The only reason I can think is if the xc_save process fails and exit()s and
>> then we want to continue execution of the domain and maybe try xc_save
>> again later. Then the first registered evtchn won't be cleaned up and we
>> would like to overwrite it when we next try xc_save.
> 
> That was the idea. If tools want to make the first user win, they can
> agree on a locking strategy between themselves.
> 
>> Arguably we should make the kernel evtchn driver aware of suspend evtchns
>> and clean them up on process destruction. Then we could tighten up Xen's
>> checking. But... It's all kind of a hassle for hardly any reward!
> 
> Agreed :)

Brendan/Keir, thanks for your clarification. I asked this because according 
discussion with Tim, we will utilize this feature for page offline also, that 
means multiple process will utilize this feature.
I will create something in tools to achieve this.

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