From mboxrd@z Thu Jan 1 00:00:00 1970 From: Sergey Fedorov Subject: Re: [RFC 1/8] cpus: pass CPUState to run_on_cpu helpers Date: Mon, 20 Jun 2016 16:07:03 +0300 Message-ID: <5767EA77.7050203@linaro.org> References: <877fdkrp1w.fsf@linaro.org> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Cc: Marcelo Tosatti , Eduardo Habkost , kvm@vger.kernel.org, Peter Crosthwaite , "Michael S. Tsirkin" , qemu-devel@nongnu.org, Alexander Graf , qemu-ppc@nongnu.org, patches@linaro.org, Paolo Bonzini , David Gibson , Richard Henderson To: =?UTF-8?Q?Alex_Benn=c3=a9e?= Return-path: In-Reply-To: <877fdkrp1w.fsf@linaro.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: qemu-devel-bounces+gceq-qemu-devel=gmane.org@nongnu.org Sender: "Qemu-devel" List-Id: kvm.vger.kernel.org On 20/06/16 16:02, Alex Bennée wrote: > Sergey Fedorov writes: > >> > From: Alex Bennée >> > >> > CPUState is a fairly common pointer to pass to these helpers. This means >> > if you need other arguments for the async_run_on_cpu case you end up >> > having to do a g_malloc to stuff additional data into the routine. For >> > the current users this isn't a massive deal but for MTTCG this gets >> > cumbersome when the only other parameter is often an address. >> > >> > This adds the typedef run_on_cpu_func for helper functions which has an >> > explicit CPUState * passed as the first parameter. All the users of >> > run_on_cpu and async_run_on_cpu have had their helpers updated to use >> > CPUState where available. >> > >> > Signed-off-by: Alex Bennée >> > Signed-off-by: Sergey Fedorov > Is this as is or did you apply the fixes from the review comments? > It's "as is" so far. I could take charge of this patch in some later re-spin. Kind regards, Sergey From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:58420) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bEyv6-0002mR-T8 for qemu-devel@nongnu.org; Mon, 20 Jun 2016 09:07:21 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1bEyv1-0002CP-Vr for qemu-devel@nongnu.org; Mon, 20 Jun 2016 09:07:15 -0400 Received: from mail-lf0-x234.google.com ([2a00:1450:4010:c07::234]:34645) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bEyv1-0002CK-O3 for qemu-devel@nongnu.org; Mon, 20 Jun 2016 09:07:11 -0400 Received: by mail-lf0-x234.google.com with SMTP id h129so36516725lfh.1 for ; Mon, 20 Jun 2016 06:07:11 -0700 (PDT) References: <877fdkrp1w.fsf@linaro.org> From: Sergey Fedorov Message-ID: <5767EA77.7050203@linaro.org> Date: Mon, 20 Jun 2016 16:07:03 +0300 MIME-Version: 1.0 In-Reply-To: <877fdkrp1w.fsf@linaro.org> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Subject: Re: [Qemu-devel] [RFC 1/8] cpus: pass CPUState to run_on_cpu helpers List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: =?UTF-8?Q?Alex_Benn=c3=a9e?= Cc: qemu-devel@nongnu.org, patches@linaro.org, Paolo Bonzini , Peter Crosthwaite , Richard Henderson , "Michael S. Tsirkin" , Eduardo Habkost , David Gibson , Alexander Graf , Marcelo Tosatti , qemu-ppc@nongnu.org, kvm@vger.kernel.org On 20/06/16 16:02, Alex Bennée wrote: > Sergey Fedorov writes: > >> > From: Alex Bennée >> > >> > CPUState is a fairly common pointer to pass to these helpers. This means >> > if you need other arguments for the async_run_on_cpu case you end up >> > having to do a g_malloc to stuff additional data into the routine. For >> > the current users this isn't a massive deal but for MTTCG this gets >> > cumbersome when the only other parameter is often an address. >> > >> > This adds the typedef run_on_cpu_func for helper functions which has an >> > explicit CPUState * passed as the first parameter. All the users of >> > run_on_cpu and async_run_on_cpu have had their helpers updated to use >> > CPUState where available. >> > >> > Signed-off-by: Alex Bennée >> > Signed-off-by: Sergey Fedorov > Is this as is or did you apply the fixes from the review comments? > It's "as is" so far. I could take charge of this patch in some later re-spin. Kind regards, Sergey