Re: [PATCH 0/2] Introduce panic hypercall

[Avi Kivity <avi@redhat.com>]

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