| Message ID | 1402630619-4408-4-git-send-email-aik@ozlabs.ru |
|---|---|
| State | New |
| Headers | show |
On Fri, 13 Jun 2014 13:36:58 +1000 Alexey Kardashevskiy <aik@ozlabs.ru> 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. > > Since the only error s390_cpu_restart() can return is ENOSYS, convert > it to QERR_UNSUPPORTED. > > Signed-off-by: Alexey Kardashevskiy <aik@ozlabs.ru> > --- > Changes: > v7: > * since now s390' are QOM'ed, add interface to them and do not create > new object > > v6: > * supported NMI interface > > v5: > * added ENOSYS -> QERR_UNSUPPORTED, qapi/qmp/qerror.h was added for this > > v4: > * s/\<nmi\>/nmi_monitor_handler/ > > v3: > * now contains both old code removal and new code insertion, easier to > track changes > > Conflicts: > hw/s390x/s390-virtio.c > --- > cpus.c | 14 -------------- > hw/s390x/s390-virtio-ccw.c | 6 ++++++ > hw/s390x/s390-virtio.c | 15 +++++++++++++++ > hw/s390x/s390-virtio.h | 3 +++ > 4 files changed, 24 insertions(+), 14 deletions(-) > Reviewed-by: Cornelia Huck <cornelia.huck@de.ibm.com>
On 06/13/2014 04:00 PM, Cornelia Huck wrote: > On Fri, 13 Jun 2014 13:36:58 +1000 > Alexey Kardashevskiy <aik@ozlabs.ru> 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 :) > >> >> Since the only error s390_cpu_restart() can return is ENOSYS, convert >> it to QERR_UNSUPPORTED. >> >> Signed-off-by: Alexey Kardashevskiy <aik@ozlabs.ru> >> --- >> Changes: >> v7: >> * since now s390' are QOM'ed, add interface to them and do not create >> new object >> >> v6: >> * supported NMI interface >> >> v5: >> * added ENOSYS -> QERR_UNSUPPORTED, qapi/qmp/qerror.h was added for this >> >> v4: >> * s/\<nmi\>/nmi_monitor_handler/ >> >> v3: >> * now contains both old code removal and new code insertion, easier to >> track changes >> >> Conflicts: >> hw/s390x/s390-virtio.c >> --- >> cpus.c | 14 -------------- >> hw/s390x/s390-virtio-ccw.c | 6 ++++++ >> hw/s390x/s390-virtio.c | 15 +++++++++++++++ >> hw/s390x/s390-virtio.h | 3 +++ >> 4 files changed, 24 insertions(+), 14 deletions(-) >> > Reviewed-by: Cornelia Huck <cornelia.huck@de.ibm.com> >
On Sat, 14 Jun 2014 12:41:50 +1000 Alexey Kardashevskiy <aik@ozlabs.ru> wrote: > On 06/13/2014 04:00 PM, Cornelia Huck wrote: > > On Fri, 13 Jun 2014 13:36:58 +1000 > > Alexey Kardashevskiy <aik@ozlabs.ru> 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()." > > > > >> > >> Since the only error s390_cpu_restart() can return is ENOSYS, convert > >> it to QERR_UNSUPPORTED. > >> > >> Signed-off-by: Alexey Kardashevskiy <aik@ozlabs.ru> > >> --- > >> Changes: > >> v7: > >> * since now s390' are QOM'ed, add interface to them and do not create > >> new object > >> > >> v6: > >> * supported NMI interface > >> > >> v5: > >> * added ENOSYS -> QERR_UNSUPPORTED, qapi/qmp/qerror.h was added for this > >> > >> v4: > >> * s/\<nmi\>/nmi_monitor_handler/ > >> > >> v3: > >> * now contains both old code removal and new code insertion, easier to > >> track changes > >> > >> Conflicts: > >> hw/s390x/s390-virtio.c > >> --- > >> cpus.c | 14 -------------- > >> hw/s390x/s390-virtio-ccw.c | 6 ++++++ > >> hw/s390x/s390-virtio.c | 15 +++++++++++++++ > >> hw/s390x/s390-virtio.h | 3 +++ > >> 4 files changed, 24 insertions(+), 14 deletions(-) > >> > > Reviewed-by: Cornelia Huck <cornelia.huck@de.ibm.com> > > > >
On 06/16/2014 05:16 PM, Cornelia Huck wrote: > On Sat, 14 Jun 2014 12:41:50 +1000 > Alexey Kardashevskiy <aik@ozlabs.ru> wrote: > >> On 06/13/2014 04:00 PM, Cornelia Huck wrote: >>> On Fri, 13 Jun 2014 13:36:58 +1000 >>> Alexey Kardashevskiy <aik@ozlabs.ru> 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. >> >>> >>>> >>>> Since the only error s390_cpu_restart() can return is ENOSYS, convert >>>> it to QERR_UNSUPPORTED. >>>> >>>> Signed-off-by: Alexey Kardashevskiy <aik@ozlabs.ru> >>>> --- >>>> Changes: >>>> v7: >>>> * since now s390' are QOM'ed, add interface to them and do not create >>>> new object >>>> >>>> v6: >>>> * supported NMI interface >>>> >>>> v5: >>>> * added ENOSYS -> QERR_UNSUPPORTED, qapi/qmp/qerror.h was added for this >>>> >>>> v4: >>>> * s/\<nmi\>/nmi_monitor_handler/ >>>> >>>> v3: >>>> * now contains both old code removal and new code insertion, easier to >>>> track changes >>>> >>>> Conflicts: >>>> hw/s390x/s390-virtio.c >>>> --- >>>> cpus.c | 14 -------------- >>>> hw/s390x/s390-virtio-ccw.c | 6 ++++++ >>>> hw/s390x/s390-virtio.c | 15 +++++++++++++++ >>>> hw/s390x/s390-virtio.h | 3 +++ >>>> 4 files changed, 24 insertions(+), 14 deletions(-) >>>> >>> Reviewed-by: Cornelia Huck <cornelia.huck@de.ibm.com> >>> >> >> >
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 <aik@ozlabs.ru> wrote: >> >>> On 06/13/2014 04:00 PM, Cornelia Huck wrote: >>>> On Fri, 13 Jun 2014 13:36:58 +1000 >>>> Alexey Kardashevskiy <aik@ozlabs.ru> 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. Alex
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 <aik@ozlabs.ru> wrote: >>> >>>> On 06/13/2014 04:00 PM, Cornelia Huck wrote: >>>>> On Fri, 13 Jun 2014 13:36:58 +1000 >>>>> Alexey Kardashevskiy <aik@ozlabs.ru> 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!
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 <aik@ozlabs.ru> wrote: >>>> >>>>> On 06/13/2014 04:00 PM, Cornelia Huck wrote: >>>>>> On Fri, 13 Jun 2014 13:36:58 +1000 >>>>>> Alexey Kardashevskiy <aik@ozlabs.ru> 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? :)
Alexey Kardashevskiy <aik@ozlabs.ru> 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 <aik@ozlabs.ru> wrote: >>>>> >>>>>> On 06/13/2014 04:00 PM, Cornelia Huck wrote: >>>>>>> On Fri, 13 Jun 2014 13:36:58 +1000 >>>>>>> Alexey Kardashevskiy <aik@ozlabs.ru> 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.
On 07/03/2014 05:11 PM, Markus Armbruster wrote: > Alexey Kardashevskiy <aik@ozlabs.ru> 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 <aik@ozlabs.ru> wrote: >>>>>> >>>>>>> On 06/13/2014 04:00 PM, Cornelia Huck wrote: >>>>>>>> On Fri, 13 Jun 2014 13:36:58 +1000 >>>>>>>> Alexey Kardashevskiy <aik@ozlabs.ru> 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. That does not seem helping though :-/
Il 14/07/2014 05:17, Alexey Kardashevskiy ha scritto: >> > No, you should politely bother them again. > > That does not seem helping though :-/ Sorry. :) Well, patch 1 is the same as v6 and for the others Cornelia and Alex can ack it. It looks good to me though. Paolo
On Mon, 14 Jul 2014 22:29:50 +0200 Paolo Bonzini <pbonzini@redhat.com> wrote: > Il 14/07/2014 05:17, Alexey Kardashevskiy ha scritto: > >> > No, you should politely bother them again. > > > > That does not seem helping though :-/ > > Sorry. :) > > Well, patch 1 is the same as v6 and for the others Cornelia and Alex can > ack it. It looks good to me though. I had r-b'd v8 of this patch and v7 of the other s390x patch, and the whole series looks fine to me.
On 07/15/2014 06:29 AM, Paolo Bonzini wrote: > Il 14/07/2014 05:17, Alexey Kardashevskiy ha scritto: >>> > No, you should politely bother them again. >> >> That does not seem helping though :-/ > > Sorry. :) > > Well, patch 1 is the same as v6 and for the others Cornelia and Alex can > ack it. It looks good to me though. Let me clarify things here. Alex rb'ed to 0/4, Cornelia rb'ed 2/4 and 3/4, so I put Alex's rb to 1&2&3&4&5, Cornelia's rb to 2&3, rebase it on top of the current upstream, repost after 2.1 is released and resume annoying people again. Is that correct? This is my current set: 5/5 pc_piix: Migrate to new NMI interface 4/5 spapr: Add support for new NMI interface 3/5 s390x: Migrate to new NMI interface 2/5 s390x: Convert QEMUMachine to MachineClass 1/5 cpus: Define callback for QEMU "nmi" command
On 07/17/2014 04:30 PM, Alexey Kardashevskiy wrote: > On 07/15/2014 06:29 AM, Paolo Bonzini wrote: >> Il 14/07/2014 05:17, Alexey Kardashevskiy ha scritto: >>>>> No, you should politely bother them again. >>> >>> That does not seem helping though :-/ >> >> Sorry. :) >> >> Well, patch 1 is the same as v6 and for the others Cornelia and Alex can >> ack it. It looks good to me though. > > > Let me clarify things here. > > Alex rb'ed to 0/4, Cornelia rb'ed 2/4 and 3/4, so I put Alex's rb to > 1&2&3&4&5, Cornelia's rb to 2&3, rebase it on top of the current upstream, > repost after 2.1 is released and resume annoying people again. Is that correct? > > This is my current set: > 5/5 pc_piix: Migrate to new NMI interface > 4/5 spapr: Add support for new NMI interface > 3/5 s390x: Migrate to new NMI interface > 2/5 s390x: Convert QEMUMachine to MachineClass > 1/5 cpus: Define callback for QEMU "nmi" command Alex, ping. ps. anecdot. "what is your problem?" "doctor, everybody ignores me" "ah I see. next patient, please" :)
On 20.08.14 12:20, Alexey Kardashevskiy wrote: > On 07/17/2014 04:30 PM, Alexey Kardashevskiy wrote: >> On 07/15/2014 06:29 AM, Paolo Bonzini wrote: >>> Il 14/07/2014 05:17, Alexey Kardashevskiy ha scritto: >>>>>> No, you should politely bother them again. >>>> >>>> That does not seem helping though :-/ >>> >>> Sorry. :) >>> >>> Well, patch 1 is the same as v6 and for the others Cornelia and Alex can >>> ack it. It looks good to me though. >> >> >> Let me clarify things here. >> >> Alex rb'ed to 0/4, Cornelia rb'ed 2/4 and 3/4, so I put Alex's rb to >> 1&2&3&4&5, Cornelia's rb to 2&3, rebase it on top of the current upstream, >> repost after 2.1 is released and resume annoying people again. Is that correct? >> >> This is my current set: >> 5/5 pc_piix: Migrate to new NMI interface >> 4/5 spapr: Add support for new NMI interface >> 3/5 s390x: Migrate to new NMI interface >> 2/5 s390x: Convert QEMUMachine to MachineClass >> 1/5 cpus: Define callback for QEMU "nmi" command > > > Alex, ping. > Uh, what exactly do you expect from me? :) Alex
On 08/20/2014 09:20 PM, Alexander Graf wrote: > > > On 20.08.14 12:20, Alexey Kardashevskiy wrote: >> On 07/17/2014 04:30 PM, Alexey Kardashevskiy wrote: >>> On 07/15/2014 06:29 AM, Paolo Bonzini wrote: >>>> Il 14/07/2014 05:17, Alexey Kardashevskiy ha scritto: >>>>>>> No, you should politely bother them again. >>>>> >>>>> That does not seem helping though :-/ >>>> >>>> Sorry. :) >>>> >>>> Well, patch 1 is the same as v6 and for the others Cornelia and Alex can >>>> ack it. It looks good to me though. >>> >>> >>> Let me clarify things here. >>> >>> Alex rb'ed to 0/4, Cornelia rb'ed 2/4 and 3/4, so I put Alex's rb to >>> 1&2&3&4&5, Cornelia's rb to 2&3, rebase it on top of the current upstream, >>> repost after 2.1 is released and resume annoying people again. Is that correct? >>> >>> This is my current set: >>> 5/5 pc_piix: Migrate to new NMI interface >>> 4/5 spapr: Add support for new NMI interface >>> 3/5 s390x: Migrate to new NMI interface >>> 2/5 s390x: Convert QEMUMachine to MachineClass >>> 1/5 cpus: Define callback for QEMU "nmi" command >> >> >> Alex, ping. >> > > > Uh, what exactly do you expect from me? :) No idea :) You could take patches to your tree. I do not understand what to do with this set now. Please help. Thanks.
On 20.08.14 13:38, Alexey Kardashevskiy wrote: > On 08/20/2014 09:20 PM, Alexander Graf wrote: >> >> >> On 20.08.14 12:20, Alexey Kardashevskiy wrote: >>> On 07/17/2014 04:30 PM, Alexey Kardashevskiy wrote: >>>> On 07/15/2014 06:29 AM, Paolo Bonzini wrote: >>>>> Il 14/07/2014 05:17, Alexey Kardashevskiy ha scritto: >>>>>>>> No, you should politely bother them again. >>>>>> >>>>>> That does not seem helping though :-/ >>>>> >>>>> Sorry. :) >>>>> >>>>> Well, patch 1 is the same as v6 and for the others Cornelia and Alex can >>>>> ack it. It looks good to me though. >>>> >>>> >>>> Let me clarify things here. >>>> >>>> Alex rb'ed to 0/4, Cornelia rb'ed 2/4 and 3/4, so I put Alex's rb to >>>> 1&2&3&4&5, Cornelia's rb to 2&3, rebase it on top of the current upstream, >>>> repost after 2.1 is released and resume annoying people again. Is that correct? >>>> >>>> This is my current set: >>>> 5/5 pc_piix: Migrate to new NMI interface >>>> 4/5 spapr: Add support for new NMI interface >>>> 3/5 s390x: Migrate to new NMI interface >>>> 2/5 s390x: Convert QEMUMachine to MachineClass >>>> 1/5 cpus: Define callback for QEMU "nmi" command >>> >>> >>> Alex, ping. >>> >> >> >> Uh, what exactly do you expect from me? :) > > No idea :) You could take patches to your tree. I do not understand what to > do with this set now. Please help. Thanks. The way I understood your last email you wanted to rebase and repost them at which point someone could pick them up :) Alex
On 08/20/2014 10:05 PM, Alexander Graf wrote: > > > On 20.08.14 13:38, Alexey Kardashevskiy wrote: >> On 08/20/2014 09:20 PM, Alexander Graf wrote: >>> >>> >>> On 20.08.14 12:20, Alexey Kardashevskiy wrote: >>>> On 07/17/2014 04:30 PM, Alexey Kardashevskiy wrote: >>>>> On 07/15/2014 06:29 AM, Paolo Bonzini wrote: >>>>>> Il 14/07/2014 05:17, Alexey Kardashevskiy ha scritto: >>>>>>>>> No, you should politely bother them again. >>>>>>> >>>>>>> That does not seem helping though :-/ >>>>>> >>>>>> Sorry. :) >>>>>> >>>>>> Well, patch 1 is the same as v6 and for the others Cornelia and Alex can >>>>>> ack it. It looks good to me though. >>>>> >>>>> >>>>> Let me clarify things here. >>>>> >>>>> Alex rb'ed to 0/4, Cornelia rb'ed 2/4 and 3/4, so I put Alex's rb to >>>>> 1&2&3&4&5, Cornelia's rb to 2&3, rebase it on top of the current upstream, >>>>> repost after 2.1 is released and resume annoying people again. Is that correct? >>>>> >>>>> This is my current set: >>>>> 5/5 pc_piix: Migrate to new NMI interface >>>>> 4/5 spapr: Add support for new NMI interface >>>>> 3/5 s390x: Migrate to new NMI interface >>>>> 2/5 s390x: Convert QEMUMachine to MachineClass >>>>> 1/5 cpus: Define callback for QEMU "nmi" command >>>> >>>> >>>> Alex, ping. >>>> >>> >>> >>> Uh, what exactly do you expect from me? :) >> >> No idea :) You could take patches to your tree. I do not understand what to >> do with this set now. Please help. Thanks. > > The way I understood your last email you wanted to rebase and repost > them at which point someone could pick them up :) I wanted answer to "is that correct?" :) And I tried replaying the patchset on top of your ppc-next, it applied. But I'll repost to make sure that we have the same thing.
On 20.08.14 14:11, Alexey Kardashevskiy wrote: > On 08/20/2014 10:05 PM, Alexander Graf wrote: >> >> >> On 20.08.14 13:38, Alexey Kardashevskiy wrote: >>> On 08/20/2014 09:20 PM, Alexander Graf wrote: >>>> >>>> >>>> On 20.08.14 12:20, Alexey Kardashevskiy wrote: >>>>> On 07/17/2014 04:30 PM, Alexey Kardashevskiy wrote: >>>>>> On 07/15/2014 06:29 AM, Paolo Bonzini wrote: >>>>>>> Il 14/07/2014 05:17, Alexey Kardashevskiy ha scritto: >>>>>>>>>> No, you should politely bother them again. >>>>>>>> >>>>>>>> That does not seem helping though :-/ >>>>>>> >>>>>>> Sorry. :) >>>>>>> >>>>>>> Well, patch 1 is the same as v6 and for the others Cornelia and Alex can >>>>>>> ack it. It looks good to me though. >>>>>> >>>>>> >>>>>> Let me clarify things here. >>>>>> >>>>>> Alex rb'ed to 0/4, Cornelia rb'ed 2/4 and 3/4, so I put Alex's rb to >>>>>> 1&2&3&4&5, Cornelia's rb to 2&3, rebase it on top of the current upstream, >>>>>> repost after 2.1 is released and resume annoying people again. Is that correct? >>>>>> >>>>>> This is my current set: >>>>>> 5/5 pc_piix: Migrate to new NMI interface >>>>>> 4/5 spapr: Add support for new NMI interface >>>>>> 3/5 s390x: Migrate to new NMI interface >>>>>> 2/5 s390x: Convert QEMUMachine to MachineClass >>>>>> 1/5 cpus: Define callback for QEMU "nmi" command >>>>> >>>>> >>>>> Alex, ping. >>>>> >>>> >>>> >>>> Uh, what exactly do you expect from me? :) >>> >>> No idea :) You could take patches to your tree. I do not understand what to >>> do with this set now. Please help. Thanks. >> >> The way I understood your last email you wanted to rebase and repost >> them at which point someone could pick them up :) > > I wanted answer to "is that correct?" :) > And I tried replaying the patchset on top of your ppc-next, it applied. But > I'll repost to make sure that we have the same thing. Oh, cool. I'll apply them as soon as I finished to recover my HD then :) Alex
Il 20/08/2014 14:12, Alexander Graf ha scritto: > > > On 20.08.14 14:11, Alexey Kardashevskiy wrote: >> On 08/20/2014 10:05 PM, Alexander Graf wrote: >>> >>> >>> On 20.08.14 13:38, Alexey Kardashevskiy wrote: >>>> On 08/20/2014 09:20 PM, Alexander Graf wrote: >>>>> >>>>> >>>>> On 20.08.14 12:20, Alexey Kardashevskiy wrote: >>>>>> On 07/17/2014 04:30 PM, Alexey Kardashevskiy wrote: >>>>>>> On 07/15/2014 06:29 AM, Paolo Bonzini wrote: >>>>>>>> Il 14/07/2014 05:17, Alexey Kardashevskiy ha scritto: >>>>>>>>>>> No, you should politely bother them again. >>>>>>>>> >>>>>>>>> That does not seem helping though :-/ >>>>>>>> >>>>>>>> Sorry. :) >>>>>>>> >>>>>>>> Well, patch 1 is the same as v6 and for the others Cornelia and Alex can >>>>>>>> ack it. It looks good to me though. >>>>>>> >>>>>>> >>>>>>> Let me clarify things here. >>>>>>> >>>>>>> Alex rb'ed to 0/4, Cornelia rb'ed 2/4 and 3/4, so I put Alex's rb to >>>>>>> 1&2&3&4&5, Cornelia's rb to 2&3, rebase it on top of the current upstream, >>>>>>> repost after 2.1 is released and resume annoying people again. Is that correct? >>>>>>> >>>>>>> This is my current set: >>>>>>> 5/5 pc_piix: Migrate to new NMI interface >>>>>>> 4/5 spapr: Add support for new NMI interface >>>>>>> 3/5 s390x: Migrate to new NMI interface >>>>>>> 2/5 s390x: Convert QEMUMachine to MachineClass >>>>>>> 1/5 cpus: Define callback for QEMU "nmi" command >>>>>> >>>>>> >>>>>> Alex, ping. >>>>>> >>>>> >>>>> >>>>> Uh, what exactly do you expect from me? :) >>>> >>>> No idea :) You could take patches to your tree. I do not understand what to >>>> do with this set now. Please help. Thanks. >>> >>> The way I understood your last email you wanted to rebase and repost >>> them at which point someone could pick them up :) >> >> I wanted answer to "is that correct?" :) >> And I tried replaying the patchset on top of your ppc-next, it applied. But >> I'll repost to make sure that we have the same thing. > > Oh, cool. I'll apply them as soon as I finished to recover my HD then :) I can apply them to uq/master too. Let me know. Paolo
diff --git a/cpus.c b/cpus.c index 5f357a4..34bf5c5 100644 --- a/cpus.c +++ b/cpus.c @@ -1481,20 +1481,6 @@ void qmp_inject_nmi(Error **errp) apic_deliver_nmi(cpu->apic_state); } } -#elif defined(TARGET_S390X) - CPUState *cs; - S390CPU *cpu; - - CPU_FOREACH(cs) { - cpu = S390_CPU(cs); - if (cpu->env.cpu_num == monitor_get_cpu_index()) { - if (s390_cpu_restart(S390_CPU(cs)) == -1) { - error_set(errp, QERR_UNSUPPORTED); - return; - } - break; - } - } #else nmi_monitor_handle(monitor_get_cpu_index(), errp); #endif diff --git a/hw/s390x/s390-virtio-ccw.c b/hw/s390x/s390-virtio-ccw.c index 05311b8..004b2c2 100644 --- a/hw/s390x/s390-virtio-ccw.c +++ b/hw/s390x/s390-virtio-ccw.c @@ -139,6 +139,7 @@ static void ccw_init(MachineState *machine) static void ccw_machine_class_init(ObjectClass *oc, void *data) { MachineClass *mc = MACHINE_CLASS(oc); + NMIClass *nc = NMI_CLASS(oc); mc->name = "s390-ccw-virtio"; mc->alias = "s390-ccw"; @@ -152,12 +153,17 @@ static void ccw_machine_class_init(ObjectClass *oc, void *data) mc->no_sdcard = 1; mc->use_sclp = 1, mc->max_cpus = 255; + nc->nmi_monitor_handler = s390_nmi; } static const TypeInfo ccw_machine_info = { .name = TYPE_S390_CCW_MACHINE, .parent = TYPE_MACHINE, .class_init = ccw_machine_class_init, + .interfaces = (InterfaceInfo[]) { + { TYPE_NMI }, + { } + }, }; static void ccw_machine_register_types(void) diff --git a/hw/s390x/s390-virtio.c b/hw/s390x/s390-virtio.c index f1e0dbc..1a75a1c 100644 --- a/hw/s390x/s390-virtio.c +++ b/hw/s390x/s390-virtio.c @@ -280,9 +280,19 @@ static void s390_init(MachineState *machine) s390_create_virtio_net((BusState *)s390_bus, "virtio-net-s390"); } +void s390_nmi(NMIState *n, int cpu_index, Error **errp) +{ + CPUState *cs = qemu_get_cpu(cpu_index); + + if (s390_cpu_restart(S390_CPU(cs))) { + error_set(errp, QERR_UNSUPPORTED); + } +} + static void s390_machine_class_init(ObjectClass *oc, void *data) { MachineClass *mc = MACHINE_CLASS(oc); + NMIClass *nc = NMI_CLASS(oc); mc->name = "s390-virtio"; mc->alias = "s390"; @@ -297,12 +307,17 @@ static void s390_machine_class_init(ObjectClass *oc, void *data) mc->no_cdrom = 1; mc->no_sdcard = 1; mc->is_default = 1; + nc->nmi_monitor_handler = s390_nmi; } static const TypeInfo s390_machine_info = { .name = TYPE_S390_MACHINE, .parent = TYPE_MACHINE, .class_init = s390_machine_class_init, + .interfaces = (InterfaceInfo[]) { + { TYPE_NMI }, + { } + }, }; static void s390_machine_register_types(void) diff --git a/hw/s390x/s390-virtio.h b/hw/s390x/s390-virtio.h index 5c405e7..33847ae 100644 --- a/hw/s390x/s390-virtio.h +++ b/hw/s390x/s390-virtio.h @@ -12,6 +12,8 @@ #ifndef HW_S390_VIRTIO_H #define HW_S390_VIRTIO_H 1 +#include "hw/nmi.h" + #define KVM_S390_VIRTIO_NOTIFY 0 #define KVM_S390_VIRTIO_RESET 1 #define KVM_S390_VIRTIO_SET_STATUS 2 @@ -26,4 +28,5 @@ void s390_init_ipl_dev(const char *kernel_filename, const char *initrd_filename, const char *firmware); void s390_create_virtio_net(BusState *bus, const char *name); +void s390_nmi(NMIState *n, int cpu_index, Error **errp); #endif
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. Since the only error s390_cpu_restart() can return is ENOSYS, convert it to QERR_UNSUPPORTED. Signed-off-by: Alexey Kardashevskiy <aik@ozlabs.ru> --- Changes: v7: * since now s390' are QOM'ed, add interface to them and do not create new object v6: * supported NMI interface v5: * added ENOSYS -> QERR_UNSUPPORTED, qapi/qmp/qerror.h was added for this v4: * s/\<nmi\>/nmi_monitor_handler/ v3: * now contains both old code removal and new code insertion, easier to track changes Conflicts: hw/s390x/s390-virtio.c --- cpus.c | 14 -------------- hw/s390x/s390-virtio-ccw.c | 6 ++++++ hw/s390x/s390-virtio.c | 15 +++++++++++++++ hw/s390x/s390-virtio.h | 3 +++ 4 files changed, 24 insertions(+), 14 deletions(-)