From: "Alex Bennée" <alex.bennee@linaro.org>
To: Eduardo Habkost <ehabkost@redhat.com>
Cc: mttcg@greensocs.com, fred.konrad@greensocs.com,
a.rigo@virtualopensystems.com, serge.fdrv@gmail.com,
cota@braap.org, qemu-devel@nongnu.org, mark.burton@greensocs.com,
pbonzini@redhat.com, jan.kiszka@siemens.com, rth@twiddle.net,
peter.maydell@linaro.org, claudio.fontana@huawei.com,
"Peter Crosthwaite" <crosthwaite.peter@gmail.com>,
"Michael S. Tsirkin" <mst@redhat.com>,
"Alexander Graf" <agraf@suse.de>,
"David Gibson" <david@gibson.dropbear.id.au>,
"Andreas Färber" <afaerber@suse.de>,
"Marcelo Tosatti" <mtosatti@redhat.com>,
"open list:PowerPC" <qemu-ppc@nongnu.org>,
"open list:Overall" <kvm@vger.kernel.org>
Subject: Re: [Qemu-devel] [RFC v1 06/12] cpus: pass CPUState to run_on_cpu helpers
Date: Wed, 20 Apr 2016 20:50:40 +0100 [thread overview]
Message-ID: <87a8koukj3.fsf@linaro.org> (raw)
In-Reply-To: <20160420185931.GS11931@thinpad.lan.raisama.net>
Eduardo Habkost <ehabkost@redhat.com> writes:
> On Fri, Apr 15, 2016 at 03:23:45PM +0100, Alex Bennée wrote:
>> 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 <alex.bennee@linaro.org>
>> ---
>> cpus.c | 15 +++++++--------
>> hw/i386/kvm/apic.c | 3 +--
>> hw/i386/kvmvapic.c | 8 ++++----
>> hw/ppc/ppce500_spin.c | 3 +--
>> hw/ppc/spapr.c | 6 ++----
>> hw/ppc/spapr_hcall.c | 12 +++++-------
>> include/qom/cpu.h | 8 +++++---
>> kvm-all.c | 20 +++++++-------------
>> target-i386/helper.c | 3 +--
>> target-i386/kvm.c | 6 ++----
>> target-s390x/cpu.c | 4 ++--
>> target-s390x/cpu.h | 7 ++-----
>
> What about target-s390x/kvm.c and target-s390x/misc_helper.c?
>
> A few other minor comments/questions below. But the patch looks
> good overall.
Good catch, I should have cross-built to ensure I got all the kvm based
helpers. I'll fix that up.
>
>> 12 files changed, 39 insertions(+), 56 deletions(-)
>>
> [...]
>> diff --git a/hw/ppc/ppce500_spin.c b/hw/ppc/ppce500_spin.c
>> index 76bd78b..e2aeef3 100644
>> --- a/hw/ppc/ppce500_spin.c
>> +++ b/hw/ppc/ppce500_spin.c
>> @@ -94,10 +94,9 @@ static void mmubooke_create_initial_mapping(CPUPPCState *env,
>> env->tlb_dirty = true;
>> }
>>
>> -static void spin_kick(void *data)
>> +static void spin_kick(CPUState *cpu, void *data)
>> {
>> SpinKick *kick = data;
>> - CPUState *cpu = CPU(kick->cpu);
>> CPUPPCState *env = &kick->cpu->env;
>
> I would set env = &cpu->env to avoid confusion. Then the SpinKick
> struct can be removed completely.
ok
>
>> SpinInfo *curspin = kick->spin;
>> hwaddr map_size = 64 * 1024 * 1024;
> [...]
>> diff --git a/hw/ppc/spapr_hcall.c b/hw/ppc/spapr_hcall.c
>> index 2dcb676..4b7fbb7 100644
>> --- a/hw/ppc/spapr_hcall.c
>> +++ b/hw/ppc/spapr_hcall.c
>> @@ -10,19 +10,18 @@
>> #include "kvm_ppc.h"
>>
>> struct SPRSyncState {
>> - CPUState *cs;
>> int spr;
>> target_ulong value;
>> target_ulong mask;
>> };
>>
>> -static void do_spr_sync(void *arg)
>> +static void do_spr_sync(CPUState *cs, void *arg)
>> {
>> struct SPRSyncState *s = arg;
>> - PowerPCCPU *cpu = POWERPC_CPU(s->cs);
>> + PowerPCCPU *cpu = POWERPC_CPU(cs);
>> CPUPPCState *env = &cpu->env;
>>
>> - cpu_synchronize_state(s->cs);
>> + cpu_synchronize_state(cs);
>> env->spr[s->spr] &= ~s->mask;
>> env->spr[s->spr] |= s->value;
>> }
>> @@ -31,7 +30,6 @@ static void set_spr(CPUState *cs, int spr, target_ulong value,
>> target_ulong mask)
>> {
>> struct SPRSyncState s = {
>> - .cs = cs,
>> .spr = spr,
>> .value = value,
>> .mask = mask
>> @@ -911,11 +909,11 @@ typedef struct {
>> Error *err;
>> } SetCompatState;
>>
>> -static void do_set_compat(void *arg)
>> +static void do_set_compat(CPUState *cs, void *arg)
>> {
>> SetCompatState *s = arg;
>>
>> - cpu_synchronize_state(CPU(s->cpu));
>> + cpu_synchronize_state(cs);
>> ppc_set_compat(s->cpu, s->cpu_version, &s->err);
>
> This is not incorrect, but inconsistent: you replaced s->cpu
> usage on the first line, but kept using s->cpu in the second
> line.
>
> Is there a specific reason you removed SPRSyncState.cs but kept
> SetCompatState.cpu?
I was trying for minimal change but your right I can do better.
>
>
>> }
>>
> [...]
>> diff --git a/target-i386/helper.c b/target-i386/helper.c
>> index 5755839..1b50f59 100644
>> --- a/target-i386/helper.c
>> +++ b/target-i386/helper.c
>> @@ -1117,11 +1117,10 @@ typedef struct MCEInjectionParams {
>> int flags;
>> } MCEInjectionParams;
>>
>> -static void do_inject_x86_mce(void *data)
>> +static void do_inject_x86_mce(CPUState *cpu, void *data)
>> {
>> MCEInjectionParams *params = data;
>> CPUX86State *cenv = ¶ms->cpu->env;
>
> I would eliminate MCEInjectionParams.cpu and set cenv = &cpu->env
> above, to avoid confusion.
>
>> - CPUState *cpu = CPU(params->cpu);
>> uint64_t *banks = cenv->mce_banks + 4 * params->bank;
>>
>> cpu_synchronize_state(cpu);
> [...]
>> diff --git a/target-s390x/cpu.h b/target-s390x/cpu.h
>> index 6d97c08..2112994 100644
>> --- a/target-s390x/cpu.h
>> +++ b/target-s390x/cpu.h
>> @@ -454,17 +454,14 @@ static inline hwaddr decode_basedisp_s(CPUS390XState *env, uint32_t ipb,
>> #define decode_basedisp_rs decode_basedisp_s
>>
>> /* helper functions for run_on_cpu() */
>> -static inline void s390_do_cpu_reset(void *arg)
>> +static inline void s390_do_cpu_reset(CPUState *cs, void *arg)
>> {
>> - CPUState *cs = arg;
>> S390CPUClass *scc = S390_CPU_GET_CLASS(cs);
>>
>> scc->cpu_reset(cs);
>> }
>> -static inline void s390_do_cpu_full_reset(void *arg)
>> +static inline void s390_do_cpu_full_reset(CPUState *cs, void *arg)
>> {
>> - CPUState *cs = arg;
>> -
>> cpu_reset(cs);
>> }
>
> The run_on_cpu callers at target-s390x/misc_helper.c still pass
> an unnecessary non-NULL void* argument, making the code
> confusing.
Will fix.
--
Alex Bennée
next prev parent reply other threads:[~2016-04-20 19:50 UTC|newest]
Thread overview: 41+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-04-15 14:23 [Qemu-devel] [RFC v1 00/12] Enable MTTCG for 32 bit arm on x86 Alex Bennée
2016-04-15 14:23 ` Alex Bennée
2016-04-15 14:23 ` [Qemu-devel] [RFC v1 01/12] include: move CPU-related definitions out of qemu-common.h Alex Bennée
2016-04-15 14:23 ` [Qemu-devel] [RFC v1 02/12] tcg/i386: Make direct jump patching thread-safe Alex Bennée
2016-04-15 14:23 ` [Qemu-devel] [RFC v1 03/12] qemu-thread: add simple test-and-set spinlock Alex Bennée
2016-04-15 14:23 ` [Qemu-devel] [RFC v1 04/12] atomic: introduce atomic_dec_fetch Alex Bennée
2016-06-02 20:34 ` Sergey Fedorov
2016-04-15 14:23 ` [Qemu-devel] [RFC v1 05/12] atomic: introduce cmpxchg_bool Alex Bennée
2016-04-15 16:22 ` Richard Henderson
2016-04-15 17:06 ` Alex Bennée
2016-06-03 16:45 ` Sergey Fedorov
2016-06-03 19:12 ` Alex Bennée
2016-06-03 19:20 ` Eric Blake
2016-04-15 14:23 ` [Qemu-devel] [RFC v1 06/12] cpus: pass CPUState to run_on_cpu helpers Alex Bennée
2016-04-20 18:59 ` Eduardo Habkost
2016-04-20 19:50 ` Alex Bennée [this message]
2016-04-15 14:23 ` [Qemu-devel] [RFC v1 07/12] cpus: introduce async_safe_run_on_cpu Alex Bennée
2016-06-05 16:01 ` Sergey Fedorov
2016-06-06 8:50 ` Alex Bennée
2016-06-06 9:38 ` Sergey Fedorov
2016-06-05 16:44 ` Sergey Fedorov
2016-04-15 14:23 ` [Qemu-devel] [RFC v1 08/12] cputlb: introduce tlb_flush_* async work Alex Bennée
2016-06-05 16:39 ` Sergey Fedorov
2016-06-06 8:54 ` Alex Bennée
2016-06-06 10:04 ` Sergey Fedorov
2016-04-15 14:23 ` [Qemu-devel] [RFC v1 09/12] translate-all: introduces tb_flush_safe Alex Bennée
2016-06-05 16:48 ` Sergey Fedorov
2016-06-06 8:54 ` Alex Bennée
2016-06-06 10:06 ` Sergey Fedorov
2016-04-15 14:23 ` [Qemu-devel] [RFC v1 10/12] arm: use tlb_flush_page_all for tlbimva[a] Alex Bennée
2016-06-05 16:54 ` Sergey Fedorov
2016-06-06 8:55 ` Alex Bennée
2016-04-15 14:23 ` [Qemu-devel] [RFC v1 11/12] arm: atomically check the exclusive value in a STREX Alex Bennée
2016-04-15 14:23 ` [Qemu-devel] [RFC v1 12/12] cpus: default MTTCG to on for 32 bit ARM on x86 Alex Bennée
2016-06-05 17:12 ` Sergey Fedorov
2016-06-06 8:58 ` Alex Bennée
2016-06-06 10:19 ` Sergey Fedorov
2016-06-06 10:26 ` Peter Maydell
2016-06-06 14:28 ` Alex Bennée
2016-06-06 14:37 ` Peter Maydell
2016-04-15 19:12 ` [Qemu-devel] [RFC v1 00/12] Enable MTTCG for 32 bit arm " Alex Bennée
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=87a8koukj3.fsf@linaro.org \
--to=alex.bennee@linaro.org \
--cc=a.rigo@virtualopensystems.com \
--cc=afaerber@suse.de \
--cc=agraf@suse.de \
--cc=claudio.fontana@huawei.com \
--cc=cota@braap.org \
--cc=crosthwaite.peter@gmail.com \
--cc=david@gibson.dropbear.id.au \
--cc=ehabkost@redhat.com \
--cc=fred.konrad@greensocs.com \
--cc=jan.kiszka@siemens.com \
--cc=kvm@vger.kernel.org \
--cc=mark.burton@greensocs.com \
--cc=mst@redhat.com \
--cc=mtosatti@redhat.com \
--cc=mttcg@greensocs.com \
--cc=pbonzini@redhat.com \
--cc=peter.maydell@linaro.org \
--cc=qemu-devel@nongnu.org \
--cc=qemu-ppc@nongnu.org \
--cc=rth@twiddle.net \
--cc=serge.fdrv@gmail.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).