Juergen,
I don''t think there''s any need to change the domain creation
interfaces.
Drop new domains into a default pool, and then they can moved out (even
immediately) by further control operations. This will avoid changes to the
domain-creation public and private interfaces.
Also, you merge the cpu_add_remove_lock into a new cpupool_lock. That''s
not
actually safe since cpu_add_remove_lock is held on entry to
stopmachine_run(). Hence I assume now cpupool_lock is, and the only way to
avoid deadlock possibilities would be for everyone to only spin_trylock on
cpupool_lock, which isn''t the case in your patch. Otherwise
stopmachine_run
can hang waiting for a CPU to enter its smr handler, while that CPU is
waiting for the cpupool_lock to be released: a deadlock scenario.
I think you''ll really need to find a method of synchronisation with cpu
hotplug which does not involve a lock that is held across stopmachine_run().
My first suggestion in this respect would be to take a look at
cpu_disable_scheduler(). This function deschedules vcpus from a cpu being
offlined, and notice you can go fairly hogwild with minimal locking
restrictions because everyone else is in a stopmachine ''safe
place'' with
irqs disabled. So they cannot concurrently conflict with you.
So hooking yourself off cpu_disable_scheduler(), or adding some other new
call-out from the end of __cpu_disable(), is quite probably the way to go to
update cpupool info, break affinities, or whatever else you need to do.
-- Keir
On 20/04/2010 10:38, "Juergen Gross"
<juergen.gross@ts.fujitsu.com> wrote:
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel