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
