This is an archived copy of the Xen.org mailing list, which we have preserved to ensure that existing links to archives are not broken. The live archive, which contains the latest emails, can be found at http://lists.xen.org/
Home Products Support Community News


[Xen-devel] Re: [Xen-changelog] Simpler domid allocation.

To: Anthony Liguori <aliguori@xxxxxxxxxx>
Subject: [Xen-devel] Re: [Xen-changelog] Simpler domid allocation.
From: Keir Fraser <Keir.Fraser@xxxxxxxxxxxx>
Date: Fri, 15 Jul 2005 16:17:38 +0100
Cc: xen-devel@xxxxxxxxxxxxxxxxxxx
Delivery-date: Fri, 15 Jul 2005 15:12:08 +0000
Envelope-to: www-data@xxxxxxxxxxxxxxxxxxx
In-reply-to: <42D7CAF2.6010900@xxxxxxxxxx>
List-help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-id: Xen developer discussion <xen-devel.lists.xensource.com>
List-post: <mailto:xen-devel@lists.xensource.com>
List-subscribe: <http://lists.xensource.com/cgi-bin/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
List-unsubscribe: <http://lists.xensource.com/cgi-bin/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
References: <E1DtL1N-000688-Qp@xxxxxxxxxxxxxxxxxxxxx> <42D7CAF2.6010900@xxxxxxxxxx>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx

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.

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. :-)

 -- 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.

Xen-devel mailing list

<Prev in Thread] Current Thread [Next in Thread>