From: Anthony Liguori <anthony@codemonkey.ws>
To: Sasha Levin <levinsasha928@gmail.com>
Cc: Wen Congyang <wency@cn.fujitsu.com>,
Gleb Natapov <gleb@redhat.com>, kvm list <kvm@vger.kernel.org>,
Jan Kiszka <jan.kiszka@siemens.com>,
qemu-devel <qemu-devel@nongnu.org>,
"linux-kernel\@vger.kernel.org" <linux-kernel@vger.kernel.org>,
Avi Kivity <avi@redhat.com>,
KAMEZAWA Hiroyuki <kamezawa.hiroyu@jp.fujitsu.com>,
rusty@rustcorp.com.au
Subject: Re: [Qemu-devel] [PATCH v7.5] kvm: notify host when the guest is panicked
Date: Sun, 22 Jul 2012 17:36:37 -0500 [thread overview]
Message-ID: <87txwzctje.fsf@codemonkey.ws> (raw)
In-Reply-To: <500C5C91.3060505@gmail.com>
Sasha Levin <levinsasha928@gmail.com> writes:
> On 07/22/2012 09:14 PM, Anthony Liguori wrote:
>> Sasha Levin <levinsasha928@gmail.com> writes:
>>
>>> On 07/21/2012 10:44 AM, Wen Congyang wrote:
>>>> We can know the guest is panicked when the guest runs on xen.
>>>> But we do not have such feature on kvm.
>>>>
>>>> Another purpose of this feature is: management app(for example:
>>>> libvirt) can do auto dump when the guest is panicked. If management
>>>> app does not do auto dump, the guest's user can do dump by hand if
>>>> he sees the guest is panicked.
>>>>
>>>> We have three solutions to implement this feature:
>>>> 1. use vmcall
>>>> 2. use I/O port
>>>> 3. use virtio-serial.
>>>>
>>>> We have decided to avoid touching hypervisor. The reason why I choose
>>>> choose the I/O port is:
>>>> 1. it is easier to implememt
>>>> 2. it does not depend any virtual device
>>>> 3. it can work when starting the kernel
>>>
>>> Was the option of implementing a virtio-watchdog driver considered?
>>>
>>> You're basically re-implementing a watchdog, a guest-host interface and a set of protocols for guest-host communications.
>>>
>>> Why can't we re-use everything we have now, push a virtio watchdog
>>> driver into drivers/watchdog/, and gain a more complete solution to
>>> detecting hangs inside the guest.
>>
>> The purpose of virtio is not to reinvent every possible type of device.
>> There are plenty of hardware watchdogs that are very suitable to be used
>> for this purpose. QEMU implements quite a few already.
>>
>> Watchdogs are not performance sensitive so there's no point in using
>> virtio.
>
> The issue here is not performance, but the adding of a brand new
> guest-host interface.
We have:
1) Virtio--this is our preferred PV interface. It needs PCI to be fully
initialized and probably will live as a module.
2) Hypercalls--this a secondary PV interface but is available very
early. It's terminated in kvm.ko which means it can only operate on
things that are logically part of the CPU and/or APIC complex.
This patch introduces a third interface which is available early like
hypercalls but not necessarily terminated in kvm.ko. That means it can
have a broader scope in functionality than (2).
We could just as well use a hypercall and have multiple commands issued
to that hypercall as a convention and add a new exit type to KVM that
sent that specific hypercall to userspace for processing.
But a PIO operation already has this behavior and requires no changes to kvm.ko.
> virtio-rng isn't performance sensitive either, yet it was implemented
> using virtio so there wouldn't be yet another interface to communicate
> between guest and host.
There isn't really an obvious discrete RNG that is widely supported.
> This patch goes ahead to add a "arch pv features" interface using
> ioports, without any idea what it might be used for beyond this
> watchdog.
It's not a watchdog--it's the opposite of a watchdog.
You know such a thing already exists in the kernel, right? S390 has had
a hypercall like this for years.
Regards,
Anthony Liguori
next prev parent reply other threads:[~2012-07-22 22:36 UTC|newest]
Thread overview: 25+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-07-21 7:12 [PATCH v7] kvm: notify host when the guest is panicked Wen Congyang
2012-07-21 7:14 ` [PATCH 1/6 v7] start vm after reseting it Wen Congyang
2012-07-21 7:14 ` [PATCH 2/6 v7] kvm: Update kernel headers Wen Congyang
2012-07-21 7:15 ` [PATCH 3/6 v7] add a new runstate: RUN_STATE_GUEST_PANICKED Wen Congyang
2012-07-21 7:16 ` [PATCH 4/6 v7] add a new qevent: QEVENT_GUEST_PANICKED Wen Congyang
2012-07-21 7:16 ` [PATCH 5/6 v7] introduce a new qom device to deal with panicked event Wen Congyang
2012-07-21 7:19 ` [PATCH 6/6 v7] allow the user to disable pv event support Wen Congyang
2012-07-21 7:19 ` [PATCH v7] kvm: notify host when the guest is panicked Jan Kiszka
2012-07-21 8:41 ` Wen Congyang
2012-07-21 8:44 ` [PATCH v7.5] " Wen Congyang
2012-07-22 11:39 ` [Qemu-devel] " Sasha Levin
2012-07-22 19:14 ` Anthony Liguori
2012-07-22 20:03 ` Sasha Levin
2012-07-22 22:36 ` Anthony Liguori [this message]
2012-07-22 23:50 ` Sasha Levin
2012-07-23 2:08 ` Wen Congyang
2012-07-23 2:07 ` Wen Congyang
2012-07-21 10:50 ` [Qemu-devel] [PATCH v7] " Sasha Levin
2012-07-22 19:22 ` Anthony Liguori
2012-07-22 20:19 ` Sasha Levin
2012-07-22 20:31 ` Sasha Levin
2012-07-22 22:29 ` Anthony Liguori
2012-07-22 23:35 ` Sasha Levin
2012-07-22 22:20 ` Anthony Liguori
2012-07-23 6:27 ` Wen Congyang
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=87txwzctje.fsf@codemonkey.ws \
--to=anthony@codemonkey.ws \
--cc=avi@redhat.com \
--cc=gleb@redhat.com \
--cc=jan.kiszka@siemens.com \
--cc=kamezawa.hiroyu@jp.fujitsu.com \
--cc=kvm@vger.kernel.org \
--cc=levinsasha928@gmail.com \
--cc=linux-kernel@vger.kernel.org \
--cc=qemu-devel@nongnu.org \
--cc=rusty@rustcorp.com.au \
--cc=wency@cn.fujitsu.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).