[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Xen-devel] Cpu pools discussion


  • To: Keir Fraser <keir.fraser@xxxxxxxxxxxxx>
  • From: Juergen Gross <juergen.gross@xxxxxxxxxxxxxx>
  • Date: Wed, 29 Jul 2009 10:52:03 +0200
  • 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 01:52:31 -0700
  • Domainkey-signature: s=s1536a; d=ts.fujitsu.com; c=nofws; q=dns; h=X-SBRSScore:X-IronPort-AV:Received:X-IronPort-AV: Received:Received:Message-ID:Date:From:Organization: User-Agent:MIME-Version:To:CC:Subject:References: In-Reply-To:X-Enigmail-Version:Content-Type: Content-Transfer-Encoding; b=T2h67kvgARfaSLaLK9Dhmjltq58PZtKfKW1PiS+md29rmDlGT+dvqLvD ftJBpj7bu8pEti0IF6zqlo5iI6YHmwAFrfH3T6/Cv86JS1eEYg2ajzfje 46sMTVlSrIHS8DFELwvb70xekOE3/Ow/VoQG2J0Hfj09juj0HnrDv6t// NQRIX5jdrzTCMwGtxH1wBpCBvt53+frsltoz/T9rvbG9yD/uv34mLHuj0 petGd89xl98bxgYgSzrPdZIUys6G0;
  • List-id: Xen developer discussion <xen-devel.lists.xensource.com>

Keir Fraser wrote:
> 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.

Sigh. I just recalled it from memory. Seems I was wrong.

> 
>> 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.

You are right.
I will add a check to ensure borrowed cpus are not allowed to change the pool.


Juergen

-- 
Juergen Gross                 Principal Developer Operating Systems
TSP ES&S SWE OS6                       Telephone: +49 (0) 89 636 47950
Fujitsu Technolgy Solutions               e-mail: juergen.gross@xxxxxxxxxxxxxx
Otto-Hahn-Ring 6                        Internet: ts.fujitsu.com
D-81739 Muenchen                 Company details: ts.fujitsu.com/imprint.html

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


 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.