| |
|
 |
|
 |
|
|
|
| |
|
|
xen-devel
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
|
|
|
| |
|
Home