[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

RE: [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


 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.