| |
|
 |
|
 |
|
|
|
| |
|
|
xen-devel
Re: [Xen-devel] Some question to changeset 17962
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 :)
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel
|
|
|
| |
|
Home