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


Re: [Xen-devel] Cpu pools discussion

To: Juergen Gross <juergen.gross@xxxxxxxxxxxxxx>
Subject: Re: [Xen-devel] Cpu pools discussion
From: Keir Fraser <keir.fraser@xxxxxxxxxxxxx>
Date: Wed, 29 Jul 2009 08:39:07 +0100
Cc: Tim Deegan <Tim.Deegan@xxxxxxxxxxxxx>, George Dunlap <dunlapg@xxxxxxxxx>, Zhigang Wang <zhigang.x.wang@xxxxxxxxxx>, "xen-devel@xxxxxxxxxxxxxxxxxxx" <xen-devel@xxxxxxxxxxxxxxxxxxx>
Delivery-date: Wed, 29 Jul 2009 00:39:38 -0700
Envelope-to: www-data@xxxxxxxxxxxxxxxxxxx
In-reply-to: <4A6FE8AD.3020308@xxxxxxxxxxxxxx>
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/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
List-unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
Thread-index: AcoQE8iZwYmpgXcPTP64aSqDyyWlQAAC96tP
Thread-topic: [Xen-devel] Cpu pools discussion
User-agent: Microsoft-Entourage/
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