Re: [Xen-devel] Cpu pools discussion

[Keir Fraser <keir.fraser@xxxxxxxxxxxxx>]

On 29/07/2009 07:14, "Juergen Gross" <juergen.gross@xxxxxxxxxxxxxx> wrote:

>> Just pulled up the patch. Actually cpupool_borrow_cpu() does not seem to
>> lock down the cpu-pool-vcpu relationship while continue_hypercall_on_cpu()
>> is running. In particular, it is clear that it does nothing if the vcpu is
>> already part of the pool that the domain is running in. But then what if the
>> cpu is removed from the pool during the borrow_cpu()/return_cpu() critical
>> region? It hardly inspires confidence.
> 
> I checked the use cases.
> All calls leading to cpupool_borrow_cpu() are done under the domctl lock.
> The same applies to all cpupool operations.

Uhhh... How did you figure that one out? I don't think one single caller of
continue_hypercall_on_cpu() holds the domctl_lock. The callers are all
sysctls and platform_ops.

> I can add an explicit check not to unassign borrowed cpus, if you like.

Your new interface ought to be responsible for its own synchronisation
needs. And if it's not you should implement the appropriate assertions
regarding e.g., spin_is_locked(), plus a code comment. It's simple
negligence to do neither.

This is all not to say that I've been convinced we should accept the feature
at all...

 -- Keir



_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel