| |
|
 |
|
 |
|
|
|
| |
|
|
xen-devel
Re: [Xen-devel] [Patch 1/6] Cpupools: hypervisor part
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@xxxxxxxxxxxxxx> wrote:
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel
|
|
|
| |
|
Home