xen-devel
[Xen-devel] Re: [Xen-changelog] Simpler domid allocation.
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
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel
|