From mboxrd@z Thu Jan 1 00:00:00 1970 From: Juergen Gross Subject: Re: [Patch] continue_hypercall_on_cpu rework using tasklets Date: Wed, 14 Apr 2010 09:25:25 +0200 Message-ID: <4BC56DE5.6040405@ts.fujitsu.com> References: Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com To: Keir Fraser Cc: "xen-devel@lists.xensource.com" List-Id: xen-devel@lists.xenproject.org Keir Fraser wrote: > On 14/04/2010 07:58, "Juergen Gross" wrote: > >>> The per-cpu area method should work fine, since Xen is non-preemptive? I >>> don't think the concurrency you are concerned about can happen. >> The tasklet knows only on which cpu it is running, so the data has to be >> stored on the target cpu. And one pcpu can be the target of concurrent calls >> from different calling cpus... > > A tasklet also takes an arbitrary ulong parameter, which you can cast to a > pointer to your informational structure. The parameter is specified via > tasklet_init(). That should suffice. I'm already using this. The problem is to find the original calling vcpu in case of a nested call of continue_hypercall_on_cpu() while not conflicting with concurrent calls from other vcpus which happen to address the same pcpu. Juergen -- Juergen Gross Principal Developer Operating Systems TSP ES&S SWE OS6 Telephone: +49 (0) 89 3222 2967 Fujitsu Technology Solutions e-mail: juergen.gross@ts.fujitsu.com Domagkstr. 28 Internet: ts.fujitsu.com D-80807 Muenchen Company details: ts.fujitsu.com/imprint.html