On Thu, Apr 07, 2011 at 10:04:00PM +0300, Blue Swirl wrote: > On Thu, Apr 7, 2011 at 9:51 PM, Gleb Natapov <gleb@xxxxxxxxxx> wrote: > > On Thu, Apr 07, 2011 at 01:32:50PM -0500, Anthony Liguori wrote: > >> On 04/07/2011 01:10 PM, Peter Maydell wrote: > >> >On 6 April 2011 20:34, Anthony Liguori<anthony@xxxxxxxxxxxxx> wrote: > >> >>http://publib.boulder.ibm.com/infocenter/lnxinfo/v3r0m0/index.jsp?topic=/liaai/crashdump/liaaicrashdumpnmiipmi.htm > >> >> > >> >>If an OS is totally hosed (spinning with interrupts disabled), and NMI can > >> >>be used to generate a crash dump. > >> >> > >> >>It's a debug feature and modelling it exactly the way we are probably makes > >> >>sense for other architectures too. The real semantics are basically force > >> >>guest crash dump. > >> >Ah, right. (There isn't really an equivalent to this on ARM since > >> >we don't have a real NMI equivalent. So any implementation for ARM > >> >qemu would be board dependent since you could wire a watchdog up to > >> >any interrupt.) > >> > > >> >Should we try to pick a command name that says what it's supposed to > >> >do rather than how it happens to be implemented on x86 ? > >> > >> Yup, I was thinking the same thing after I sent the note above. If > >> we call it 'force-crash-dump', we can implement it as an NMI on > >> target-i386 and potentially as something else on a different target. > >> > > NMI does not have to generate crash dump on every guest we support. > > Actually even for windows guest it does not generate one without > > tweaking registry. For all I know there is a guest that checks mail when > > NMI arrives. Lets give meaningful name, like inject-nmi, for nmi > > injection command. > > I'd prefer something more generic like these: > raise /apic@fee00000:l1int > lower /i44FX-pcihost/e1000@xxxx/pinD > > The clumsier syntax shouldn't be a problem, since this would be a > system developer tool. > > Some kind of IRQ registration would be needed for this to work without > lots of changes. True. The ability to trigger any interrupt line is very useful for debugging. I often re-implement it during debug. -- Gleb. -- 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
