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

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


 


Rackspace

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