Re: [Qemu-devel] [PATCH 2/2 V7] qemu,qmp: add inject-nmi qmp command

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

 



On Wed, 06 Apr 2011 20:17:47 +0200
Jan Kiszka <jan.kiszka@xxxxxxxxxxx> wrote:

> On 2011-04-06 20:08, Luiz Capitulino wrote:
> > On Wed, 06 Apr 2011 13:03:37 -0500
> > Anthony Liguori <anthony@xxxxxxxxxxxxx> wrote:
> > 
> >> On 04/06/2011 12:47 PM, Luiz Capitulino wrote:
> >>> On Mon, 04 Apr 2011 08:05:48 -0500
> >>> Anthony Liguori<anthony@xxxxxxxxxxxxx>  wrote:
> >>>
> >>>> On 04/04/2011 07:54 AM, Avi Kivity wrote:
> >>>>> On 04/04/2011 01:59 PM, Daniel P. Berrange wrote:
> >>>>>> Interesting that with HMP you need to specify a single CPU index, but
> >>>>>> with QMP it is injecting to all CPUs at once. Is there any compelling
> >>>>>> reason why we'd ever need the ability to only inject to a single CPU
> >>>>>> from an app developer POV ?
> >>>>> When a PC has an NMI button, it is (I presume) connected to all CPUs'
> >>>>> LINT1 pin, which is often configured as an NMI input.  So the all-cpu
> >>>>> variant corresponds to real hardware, while the single-cpu variant
> >>>>> doesn't.
> >>>>>
> >>>>> wrt the app developer POV, the only use I'm aware of is that you can
> >>>>> configure Windows to dump core when the NMI button is pressed and thus
> >>>>> debug driver problems.  It's likely more reliable when sent to all cpus.
> >>>> It either needs to be removed from HMP or added to QMP.  HMP shouldn't
> >>>> have more features than QMP (even if those features are non-sensible).
> >>> Is anyone against changing HMP behavior to send it to all CPUs?
> >>
> >> Makes sense to me.
> > 
> > So, Lai, in order to get this merged could you please do the following:
> > 
> >  1. Address checkpath.pl errors
> > 
> >  2. Change the HMP to use this implementation, which send the NMI
> >     to all CPUs
> 
> HMP is currently x86-only, thus it's probably OK to model it after some
> PC feature (though I don't know if there aren't NMI buttons with BP-only
> wirings). But will the consolidate version be defined for all
> architectures? We should avoid "exporting" x86-specific assumptions.

Right, but honestly speaking, I don't know how this works for other arches.

So, the best thing to do is to have a general design that can be used
by any architecture. Of course that we can also add a new command later
if needed.
--
To unsubscribe from this list: send the line "unsubscribe kvm" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html


[Index of Archives]     [KVM ARM]     [KVM ia64]     [KVM ppc]     [Virtualization Tools]     [Spice Development]     [Libvirt]     [Libvirt Users]     [Linux USB Devel]     [Linux Audio Users]     [Yosemite Questions]     [Linux Kernel]     [Linux SCSI]     [XFree86]
  Powered by Linux