All of lore.kernel.org
 help / color / mirror / Atom feed
From: Wen Congyang <wency@cn.fujitsu.com>
To: Marcelo Tosatti <mtosatti@redhat.com>
Cc: Hu Tao <hutao@cn.fujitsu.com>, kvm list <kvm@vger.kernel.org>,
	qemu-devel <qemu-devel@nongnu.org>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	Avi Kivity <avi@redhat.com>,
	"Daniel P. Berrange" <berrange@redhat.com>,
	KAMEZAWA Hiroyuki <kamezawa.hiroyu@jp.fujitsu.com>,
	Jan Kiszka <jan.kiszka@siemens.com>,
	Gleb Natapov <gleb@redhat.com>, Blue Swirl <blauwirbel@gmail.com>,
	Eric Blake <eblake@redhat.com>, Andrew Jones <drjones@redhat.com>,
	Sasha Levin <levinsasha928@gmail.com>,
	Luiz Capitulino <lcapitulino@redhat.com>
Subject: Re: [PATCH v11] kvm: notify host when the guest is panicked
Date: Wed, 31 Oct 2012 09:48:04 +0800	[thread overview]
Message-ID: <50908354.5070608@cn.fujitsu.com> (raw)
In-Reply-To: <20121031011256.GC12325@amt.cnet>

At 10/31/2012 09:12 AM, Marcelo Tosatti Wrote:
> On Thu, Oct 25, 2012 at 11:42:32AM +0800, Hu Tao 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
> 
> It has been asked earlier why a simple virtio device is not usable
> for this (with no response IIRC).

1. We can't use virtio device when the kernel is booting.
2. The virtio's driver can be built as a module, and if it is not loaded
   and the kernel is panicked, there is no way to notify the host.
3. I/O port is more reliable than virtio device.
   If virtio's driver has some bug, and it cause kernel panicked, we can't
   use it. The I/O port is more reliable because it only depends on notifier
   chain(If we use virtio device, it also depends on notifier chain).

Thanks
Wen Congyang

> 
> Also, there is no high level documentation: purpose of the interface,
> how a management application should use it, etc.
> 
> 

WARNING: multiple messages have this Message-ID (diff)
From: Wen Congyang <wency@cn.fujitsu.com>
To: Marcelo Tosatti <mtosatti@redhat.com>
Cc: Andrew Jones <drjones@redhat.com>, Gleb Natapov <gleb@redhat.com>,
	kvm list <kvm@vger.kernel.org>, Hu Tao <hutao@cn.fujitsu.com>,
	qemu-devel <qemu-devel@nongnu.org>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	Blue Swirl <blauwirbel@gmail.com>, Avi Kivity <avi@redhat.com>,
	Jan Kiszka <jan.kiszka@siemens.com>,
	Luiz Capitulino <lcapitulino@redhat.com>,
	KAMEZAWA Hiroyuki <kamezawa.hiroyu@jp.fujitsu.com>,
	Sasha Levin <levinsasha928@gmail.com>
Subject: Re: [Qemu-devel] [PATCH v11] kvm: notify host when the guest is panicked
Date: Wed, 31 Oct 2012 09:48:04 +0800	[thread overview]
Message-ID: <50908354.5070608@cn.fujitsu.com> (raw)
In-Reply-To: <20121031011256.GC12325@amt.cnet>

At 10/31/2012 09:12 AM, Marcelo Tosatti Wrote:
> On Thu, Oct 25, 2012 at 11:42:32AM +0800, Hu Tao 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
> 
> It has been asked earlier why a simple virtio device is not usable
> for this (with no response IIRC).

1. We can't use virtio device when the kernel is booting.
2. The virtio's driver can be built as a module, and if it is not loaded
   and the kernel is panicked, there is no way to notify the host.
3. I/O port is more reliable than virtio device.
   If virtio's driver has some bug, and it cause kernel panicked, we can't
   use it. The I/O port is more reliable because it only depends on notifier
   chain(If we use virtio device, it also depends on notifier chain).

Thanks
Wen Congyang

> 
> Also, there is no high level documentation: purpose of the interface,
> how a management application should use it, etc.
> 
> 

  reply	other threads:[~2012-10-31  1:48 UTC|newest]

Thread overview: 42+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-10-25  3:42 [PATCH v11] kvm: notify host when the guest is panicked Hu Tao
2012-10-25  3:42 ` [Qemu-devel] " Hu Tao
2012-10-25  3:42 ` [PATCH v11 1/6] start vm after reseting it Hu Tao
2012-10-25  3:42   ` [Qemu-devel] " Hu Tao
2012-10-25  3:42 ` [PATCH v11 2/6] update kernel headers Hu Tao
2012-10-25  3:42   ` [Qemu-devel] " Hu Tao
2012-10-25  3:42 ` [PATCH v11 3/6] add a new runstate: RUN_STATE_GUEST_PANICKED Hu Tao
2012-10-25  3:42   ` [Qemu-devel] " Hu Tao
2012-10-25  3:42 ` [PATCH v11 4/6] add a new qevent: QEVENT_GUEST_PANICKED Hu Tao
2012-10-25  3:42   ` [Qemu-devel] " Hu Tao
2012-10-25  3:42 ` [PATCH v11 5/6] introduce a new qom device to deal with panicked event Hu Tao
2012-10-25  3:42   ` [Qemu-devel] " Hu Tao
2012-10-25  3:42 ` [PATCH v11 6/6] allower the user to disable pv event support Hu Tao
2012-10-25  3:42   ` [Qemu-devel] " Hu Tao
2012-10-31  1:12 ` [PATCH v11] kvm: notify host when the guest is panicked Marcelo Tosatti
2012-10-31  1:12   ` [Qemu-devel] " Marcelo Tosatti
2012-10-31  1:12   ` Marcelo Tosatti
2012-10-31  1:48   ` Wen Congyang [this message]
2012-10-31  1:48     ` [Qemu-devel] " Wen Congyang
2012-10-31  2:30     ` Sasha Levin
2012-10-31  2:30       ` [Qemu-devel] " Sasha Levin
2012-10-31  2:30       ` Sasha Levin
2012-10-31 23:15       ` Marcelo Tosatti
2012-10-31 23:15         ` [Qemu-devel] " Marcelo Tosatti
2012-10-31 23:15         ` Marcelo Tosatti
2012-11-06  1:58       ` Hu Tao
2012-11-06  1:58         ` [Qemu-devel] " Hu Tao
2012-11-09 20:17         ` Sasha Levin
2012-11-09 20:17           ` [Qemu-devel] " Sasha Levin
2012-11-09 20:17           ` Sasha Levin
2012-11-13  2:19           ` Marcelo Tosatti
2012-11-13  2:19             ` [Qemu-devel] " Marcelo Tosatti
2012-11-20 10:09             ` Hu Tao
2012-11-20 10:09               ` [Qemu-devel] " Hu Tao
2012-11-20 21:33               ` Marcelo Tosatti
2012-11-20 21:33                 ` [Qemu-devel] " Marcelo Tosatti
2012-11-20 21:33                 ` Marcelo Tosatti
2012-11-21  9:39                 ` Gleb Natapov
2012-11-21  9:39                   ` [Qemu-devel] " Gleb Natapov
2012-11-21  9:39                   ` Gleb Natapov
2012-11-22  7:21                   ` Hu Tao
2012-11-22  7:21                     ` [Qemu-devel] " Hu Tao

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=50908354.5070608@cn.fujitsu.com \
    --to=wency@cn.fujitsu.com \
    --cc=avi@redhat.com \
    --cc=berrange@redhat.com \
    --cc=blauwirbel@gmail.com \
    --cc=drjones@redhat.com \
    --cc=eblake@redhat.com \
    --cc=gleb@redhat.com \
    --cc=hutao@cn.fujitsu.com \
    --cc=jan.kiszka@siemens.com \
    --cc=kamezawa.hiroyu@jp.fujitsu.com \
    --cc=kvm@vger.kernel.org \
    --cc=lcapitulino@redhat.com \
    --cc=levinsasha928@gmail.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mtosatti@redhat.com \
    --cc=qemu-devel@nongnu.org \
    /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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.