qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-devel] [PATCH 0/2] Introduce panic hypercall


From: Avi Kivity
Subject: Re: [Qemu-devel] [PATCH 0/2] Introduce panic hypercall
Date: Mon, 20 Jun 2011 19:34:57 +0300
User-agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.17) Gecko/20110428 Fedora/3.1.10-1.fc15 Thunderbird/3.1.10

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




reply via email to

[Prev in Thread] Current Thread [Next in Thread]