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. Jan -- Siemens AG, Corporate Technology, CT T DE IT 1 Corporate Competence Center Embedded Linux -- 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
