From mboxrd@z Thu Jan 1 00:00:00 1970 From: Anthony Liguori Subject: Re: [Xen-changelog] Simpler domid allocation. Date: Fri, 15 Jul 2005 10:40:33 -0500 Message-ID: <42D7D8F1.7090609@us.ibm.com> References: <42D7CAF2.6010900@us.ibm.com> <3db553b59e1018c2a42f67d5935cf22f@cl.cam.ac.uk> Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <3db553b59e1018c2a42f67d5935cf22f@cl.cam.ac.uk> List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com To: Keir Fraser Cc: xen-devel@lists.xensource.com List-Id: xen-devel@lists.xenproject.org Keir Fraser wrote: > > I think you misread the allocation scheme -- it still allocates > increasing domid's in turn but just doesn;t arbitrarily decide to wrap > at e.g., domid==100. So your fears over immediate domid reuse are > unfounded. Indeed. I read the removed comment as the new functionality. Should not read patches before having any caffeine :-) > I understand your fears w.r.t. decentralised tools. One thing I think > we will end up doing is adding the domain uuid (big unique domain > identifier) to Xen. Xen will still work in terms of the short 16-bit > domids, but control tools will be able to read out this extra unique > key value which they can use to protect themselves against domid reuse > in the absence of some other trusted authority. Invaluable for > debugging screwed-up machine states too. :-) Excellent. The UUID would be part of the struct domain in Xen? Would Xen create it and the tools just have an interface to get it? I'd be happy to submit a patch to add this as it would be very useful for the tools (since it effectively eliminates the possibility of race conditions). Thanks, Anthony Liguori > -- Keir > > On 15 Jul 2005, at 15:40, Anthony Liguori wrote: > >> This change worries me a bit because I believe it increases the >> likelihood of subtle race conditions in the tools. It's now likely >> that if one destroys a domain and immediately creates a new domain, >> when the tools finally see the VIRQ, they'll be very confused since >> the domid appears to be valid. >> >> The situation is worse for a destroyed domain. A destroy does not >> generate a VIRQ in which case if the destroy and create happen within >> whatever the tools polling interval is, it will appear to the tool >> that the destroy just didn't work. >> >> The solution would be to have a completely serialized tool chain >> although that prevents having multiple simulatenous tools running at >> the same time or a distribute tool chain where most things don't >> require a central daemon. >> >> The old domid allocation was odd but it kept life easier by making >> race conditions difficult to create. > > >