Re: [Qemu-devel] [RFC v2 02/11] cpus: pass CPUState to run_on_cpu helpers

[Christian Borntraeger]

On 07/11/2016 02:38 PM, Sergey Fedorov wrote:
> On 11/07/16 15:36, Christian Borntraeger wrote:
>> On 07/06/2016 11:14 PM, Sergey Fedorov wrote:
>>> From: Alex Bennée <address@hidden>
>>>
>>> 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 <address@hidden>
>>> [Sergey Fedorov:
>>>  - eliminate more CPUState in user data;
>>>  - remove unnecessary user data passing;
>>>  - fix target-s390x/kvm.c and target-s390x/misc_helper.c]
>>> Signed-off-by: Sergey Fedorov <address@hidden>
>>> ---
>>>
>>> Changes in v2:
>>>  - eliminate more CPUState in user data
>>>  - remove unnecessary user data passing
>>>  - fix target-s390x/kvm.c and target-s390x/misc_helper.c
>>>
>>> ---
>>>  cpus.c                     | 15 ++++---
>>>  hw/i386/kvm/apic.c         |  3 +-
>>>  hw/i386/kvmvapic.c         |  6 +--
>>>  hw/ppc/ppce500_spin.c      | 31 +++++----------
>>>  hw/ppc/spapr.c             |  6 +--
>>>  hw/ppc/spapr_hcall.c       | 17 ++++----
>>>  include/qom/cpu.h          |  8 ++--
>>>  kvm-all.c                  | 21 ++++------
>>>  target-i386/helper.c       | 19 ++++-----
>>>  target-i386/kvm.c          |  6 +--
>>>  target-s390x/cpu.c         |  4 +-
>>>  target-s390x/cpu.h         |  7 +---
>>>  target-s390x/kvm.c         | 98 
>>> +++++++++++++++++++++++-----------------------
>>>  target-s390x/misc_helper.c |  4 +-
>>>  14 files changed, 108 insertions(+), 137 deletions(-)
>> s390 parts look ok.
> 
> Can this be considered as "Acked-by" or not exactly?

I looked through all changes, so maybe an Reviewed-by (s390 parts) is ok.