qemu-ppc
[Top][All Lists]
Advanced

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

Re: [Qemu-ppc] [Qemu-devel] [PATCH v7 3/4] s390x: Migrate to new NMI int


From: Markus Armbruster
Subject: Re: [Qemu-ppc] [Qemu-devel] [PATCH v7 3/4] s390x: Migrate to new NMI interface
Date: Thu, 03 Jul 2014 09:11:30 +0200
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/24.3 (gnu/linux)

Alexey Kardashevskiy <address@hidden> writes:

> On 06/23/2014 11:32 PM, Alexey Kardashevskiy wrote:
>> On 06/16/2014 06:37 PM, Alexander Graf wrote:
>>>
>>> On 16.06.14 10:33, Alexey Kardashevskiy wrote:
>>>> On 06/16/2014 05:16 PM, Cornelia Huck wrote:
>>>>> On Sat, 14 Jun 2014 12:41:50 +1000
>>>>> Alexey Kardashevskiy <address@hidden> wrote:
>>>>>
>>>>>> On 06/13/2014 04:00 PM, Cornelia Huck wrote:
>>>>>>> On Fri, 13 Jun 2014 13:36:58 +1000
>>>>>>> Alexey Kardashevskiy <address@hidden> wrote:
>>>>>>>
>>>>>>>> This implements an NMI interface for s390 and s390-ccw machines.
>>>>>>>>
>>>>>>>> This removes #ifdef s390 branch in qmp_inject_nmi so new s390's
>>>>>>>> nmi_monitor_handler() callback is going to be used for NMI.
>>>>>>>>
>>>>>>>> Since nmi_monitor_handler()-calling code is platform independent,
>>>>>>>> CPUState::cpu_index is used instead of S390CPU::env.cpu_num.
>>>>>>>> There should not be any change in behaviour as both @cpu_index and
>>>>>>>> @cpu_num are global CPU numbers.
>>>>>>>>
>>>>>>>> Also, s390_cpu_restart() takes care of preforming operations in
>>>>>>>> the specific CPU thread so no extra measure is required here either.
>>>>>>> I find this paragraph a bit confusing; I'd just remove it.
>>>>>> Besides bad english (please feel free to adjust it), what else is
>>>>>> confusing
>>>>>> here? I put it there because the spapr patch makes use of
>>>>>> async_run_on_cpu() and maintainers may ask why I do not do the same for
>>>>>> other platforms. This way I hoped I could reduce number of versions to
>>>>>> post :)
>>>>> What about
>>>>>
>>>>> "Note that s390_cpu_restart() already takes care of the specified cpu,
>>>>> so we don't need to schedule via async_run_on_cpu()."
>>>> I fail to see how exactly this is better or different but ok :)
>>>>
>>>>
>>>> Alex, should I repost it with Cornelia's suggestion? What should happen
>>>> next to this patchset? Who is supposed to pick it up? Thanks.
>>>
>>> Just post v8 of that single patch with the right message-id as reference. I
>>> can pick up the patches, but I'd like at least an ack from Paolo on the
>>> whole set.
>> 
>> 
>> Anybody, ping? Or we are waiting till x86 machines got QOM'ed and then I'll
>> repost it with x86 NMI handler? Thanks!
>
>
> Paolo promised to ack (in irc) and obviously forgot :) Should I give up and
> stop bothering noble people? :)

No, you should politely bother them again.



reply via email to

[Prev in Thread] Current Thread [Next in Thread]