On 06/20/2011 07:26 PM, Daniel Gollub wrote:
>
> I agree. But let's do this via a device, this way kvm need not be changed.
Is a device reliable enough if the guest kernel crashes?
Do you mean something like a hardware watchdog?
I'm proposing a 1:1 equivalent. Instead of issuing a hypercall that
tells the host about the panic, write to an I/O port that tells the host
about the panic.
>
> Do ILO cards / IPMI support something like this? We could follow their
> lead in that case.
The only two things which came to my mind are:
* NMI (aka. ipmitool diag) - already available in qemu/kvm - but requires
in-guest kexec/kdump
* Hardware-Watchdog (also available in qemu/libvirt)
A watchdog has the advantage that is also detects lockups.
In fact you could implement the panic device via the existing
watchdogs. Simply program the timer for the minimum interval and
*don't* service the interrupt. This would work for non-virt setups as
well as another way to issue a reset.
lguest and xen have something similar. They also have an hypercall which get
called by a function registered in the panic_notifier_list. Not quite sure if
you want to follow their lead.
We could do the same, except s/hypercall/writel/.
Something I forgot to mention: This panic hypercall could also sit within an
external kernel module ... to support (legacy) distribution.
Yes.
>
> > This series does need to introduce a QMP event notification upon
> > crash, so that the crash notification can be propagated to mgmt
> > layers above QEMU.
>
> Yes.
Already done. I posted the QEMU relevant changes as a separated series to the
KVM list ... since the initial implementation is KVM specific (KVM hypercall)
--
error compiling committee.c: too many arguments to function
--
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
