From: Marcelo Tosatti <mtosatti@redhat.com>
To: Hu Tao <hutao@cn.fujitsu.com>
Cc: Andrew Jones <drjones@redhat.com>, kvm list <kvm@vger.kernel.org>,
Jan Kiszka <jan.kiszka@siemens.com>,
qemu-devel <qemu-devel@nongnu.org>,
Gleb Natapov <gleb@redhat.com>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
Blue Swirl <blauwirbel@gmail.com>, Avi Kivity <avi@redhat.com>,
Luiz Capitulino <lcapitulino@redhat.com>,
KAMEZAWA Hiroyuki <kamezawa.hiroyu@jp.fujitsu.com>,
Sasha Levin <levinsasha928@gmail.com>
Subject: Re: [PATCH v11] kvm: notify host when the guest is panicked
Date: Tue, 20 Nov 2012 19:33:49 -0200 [thread overview]
Message-ID: <20121120213349.GA31355@amt.cnet> (raw)
In-Reply-To: <20121120100948.GB17311@localhost.localdomain>
On Tue, Nov 20, 2012 at 06:09:48PM +0800, Hu Tao wrote:
> Hi Marcelo,
>
> On Tue, Nov 13, 2012 at 12:19:08AM -0200, Marcelo Tosatti wrote:
> > On Fri, Nov 09, 2012 at 03:17:39PM -0500, Sasha Levin wrote:
> > > On Mon, Nov 5, 2012 at 8:58 PM, Hu Tao <hutao@cn.fujitsu.com> wrote:
> > > > But in the case of panic notification, more dependency means more
> > > > chances of failure of panic notification. Say, if we use a virtio device
> > > > to do panic notification, then we will fail if: virtio itself has
> > > > problems, virtio for some reason can't be deployed(neither built-in or
> > > > as a module), or guest doesn't support virtio, etc.
> > >
> > > Add polling to your virtio device. If it didn't notify of a panic but
> > > taking more than 20 sec to answer your poll request you can assume
> > > it's dead.
> > >
> > > Actually, just use virtio-serial and something in userspace on the guest.
> >
> > They want the guest to stop, so a memory dump can be taken by management
> > interface.
> >
> > Hu Tao, lets assume port I/O is the preferred method for communication.
>
> Okey.
>
> > Now, the following comments have still not been addressed:
> >
> > 1) Lifecycle of the stopped guest and interaction with other stopped
> > states in QEMU.
>
> Patch 3 already deals with run state transitions. But in case I'm
> missing something, could you be more specific?
- What are the possibilities during migration? Say:
- migration starts.
- guest panics.
- migration starts vm on other side?
- Guest stopped due to EIO.
- guest vcpuN panics, VMEXIT but still outside QEMU.
- QEMU EIO error, stop vm.
- guest vcpuN completes, processes IO exit.
- system_reset due to panic.
- Add all possibilities that should be verified (that is, interaction
of this feature with other stopped states in QEMU).
---
- What happens if the guest has reboot-on-panic configured? Does it take
precedence over hypervisor notification?
Out of curiosity, does kexec support memory dumping?
> > 2) Format of the interface for other architectures (you can choose
> > a different KVM supported architecture and write an example).
> >
> > 3) Clear/documented management interface for the feature.
>
> It is documented in patch 0: Documentation/virtual/kvm/pv_event.txt.
> Does it need to be improved?
This is documentation for the host<->guest interface. There is no
documentation on the interface for management.
WARNING: multiple messages have this Message-ID (diff)
From: Marcelo Tosatti <mtosatti@redhat.com>
To: Hu Tao <hutao@cn.fujitsu.com>
Cc: Sasha Levin <levinsasha928@gmail.com>,
Wen Congyang <wency@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>,
Luiz Capitulino <lcapitulino@redhat.com>
Subject: Re: [PATCH v11] kvm: notify host when the guest is panicked
Date: Tue, 20 Nov 2012 19:33:49 -0200 [thread overview]
Message-ID: <20121120213349.GA31355@amt.cnet> (raw)
In-Reply-To: <20121120100948.GB17311@localhost.localdomain>
On Tue, Nov 20, 2012 at 06:09:48PM +0800, Hu Tao wrote:
> Hi Marcelo,
>
> On Tue, Nov 13, 2012 at 12:19:08AM -0200, Marcelo Tosatti wrote:
> > On Fri, Nov 09, 2012 at 03:17:39PM -0500, Sasha Levin wrote:
> > > On Mon, Nov 5, 2012 at 8:58 PM, Hu Tao <hutao@cn.fujitsu.com> wrote:
> > > > But in the case of panic notification, more dependency means more
> > > > chances of failure of panic notification. Say, if we use a virtio device
> > > > to do panic notification, then we will fail if: virtio itself has
> > > > problems, virtio for some reason can't be deployed(neither built-in or
> > > > as a module), or guest doesn't support virtio, etc.
> > >
> > > Add polling to your virtio device. If it didn't notify of a panic but
> > > taking more than 20 sec to answer your poll request you can assume
> > > it's dead.
> > >
> > > Actually, just use virtio-serial and something in userspace on the guest.
> >
> > They want the guest to stop, so a memory dump can be taken by management
> > interface.
> >
> > Hu Tao, lets assume port I/O is the preferred method for communication.
>
> Okey.
>
> > Now, the following comments have still not been addressed:
> >
> > 1) Lifecycle of the stopped guest and interaction with other stopped
> > states in QEMU.
>
> Patch 3 already deals with run state transitions. But in case I'm
> missing something, could you be more specific?
- What are the possibilities during migration? Say:
- migration starts.
- guest panics.
- migration starts vm on other side?
- Guest stopped due to EIO.
- guest vcpuN panics, VMEXIT but still outside QEMU.
- QEMU EIO error, stop vm.
- guest vcpuN completes, processes IO exit.
- system_reset due to panic.
- Add all possibilities that should be verified (that is, interaction
of this feature with other stopped states in QEMU).
---
- What happens if the guest has reboot-on-panic configured? Does it take
precedence over hypervisor notification?
Out of curiosity, does kexec support memory dumping?
> > 2) Format of the interface for other architectures (you can choose
> > a different KVM supported architecture and write an example).
> >
> > 3) Clear/documented management interface for the feature.
>
> It is documented in patch 0: Documentation/virtual/kvm/pv_event.txt.
> Does it need to be improved?
This is documentation for the host<->guest interface. There is no
documentation on the interface for management.
WARNING: multiple messages have this Message-ID (diff)
From: Marcelo Tosatti <mtosatti@redhat.com>
To: Hu Tao <hutao@cn.fujitsu.com>
Cc: Andrew Jones <drjones@redhat.com>, kvm list <kvm@vger.kernel.org>,
Jan Kiszka <jan.kiszka@siemens.com>,
qemu-devel <qemu-devel@nongnu.org>,
Gleb Natapov <gleb@redhat.com>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
Blue Swirl <blauwirbel@gmail.com>, Avi Kivity <avi@redhat.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: Tue, 20 Nov 2012 19:33:49 -0200 [thread overview]
Message-ID: <20121120213349.GA31355@amt.cnet> (raw)
In-Reply-To: <20121120100948.GB17311@localhost.localdomain>
On Tue, Nov 20, 2012 at 06:09:48PM +0800, Hu Tao wrote:
> Hi Marcelo,
>
> On Tue, Nov 13, 2012 at 12:19:08AM -0200, Marcelo Tosatti wrote:
> > On Fri, Nov 09, 2012 at 03:17:39PM -0500, Sasha Levin wrote:
> > > On Mon, Nov 5, 2012 at 8:58 PM, Hu Tao <hutao@cn.fujitsu.com> wrote:
> > > > But in the case of panic notification, more dependency means more
> > > > chances of failure of panic notification. Say, if we use a virtio device
> > > > to do panic notification, then we will fail if: virtio itself has
> > > > problems, virtio for some reason can't be deployed(neither built-in or
> > > > as a module), or guest doesn't support virtio, etc.
> > >
> > > Add polling to your virtio device. If it didn't notify of a panic but
> > > taking more than 20 sec to answer your poll request you can assume
> > > it's dead.
> > >
> > > Actually, just use virtio-serial and something in userspace on the guest.
> >
> > They want the guest to stop, so a memory dump can be taken by management
> > interface.
> >
> > Hu Tao, lets assume port I/O is the preferred method for communication.
>
> Okey.
>
> > Now, the following comments have still not been addressed:
> >
> > 1) Lifecycle of the stopped guest and interaction with other stopped
> > states in QEMU.
>
> Patch 3 already deals with run state transitions. But in case I'm
> missing something, could you be more specific?
- What are the possibilities during migration? Say:
- migration starts.
- guest panics.
- migration starts vm on other side?
- Guest stopped due to EIO.
- guest vcpuN panics, VMEXIT but still outside QEMU.
- QEMU EIO error, stop vm.
- guest vcpuN completes, processes IO exit.
- system_reset due to panic.
- Add all possibilities that should be verified (that is, interaction
of this feature with other stopped states in QEMU).
---
- What happens if the guest has reboot-on-panic configured? Does it take
precedence over hypervisor notification?
Out of curiosity, does kexec support memory dumping?
> > 2) Format of the interface for other architectures (you can choose
> > a different KVM supported architecture and write an example).
> >
> > 3) Clear/documented management interface for the feature.
>
> It is documented in patch 0: Documentation/virtual/kvm/pv_event.txt.
> Does it need to be improved?
This is documentation for the host<->guest interface. There is no
documentation on the interface for management.
next prev parent reply other threads:[~2012-11-20 21:33 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
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 [this message]
2012-11-20 21:33 ` 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=20121120213349.GA31355@amt.cnet \
--to=mtosatti@redhat.com \
--cc=avi@redhat.com \
--cc=blauwirbel@gmail.com \
--cc=drjones@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=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.