virtualization.lists.linux-foundation.org archive mirror
 help / color / mirror / Atom feed
From: Sasha Levin <levinsasha928@gmail.com>
To: Rusty Russell <rusty@rustcorp.com.au>
Cc: wency@cn.fujitsu.com, kvm@vger.kernel.org, mst@redhat.com,
	linux-kernel@vger.kernel.org,
	virtualization@lists.linux-foundation.org, penberg@kernel.org,
	avi@redhat.com, anthony@codemonkey.ws
Subject: Re: [RFC 0/2] virtio: provide a way for host to monitor critical events in the device
Date: Tue, 24 Jul 2012 14:23:24 +0200	[thread overview]
Message-ID: <500E93BC.8010600@gmail.com> (raw)
In-Reply-To: <87a9yprc4v.fsf@rustcorp.com.au>

On 07/24/2012 06:55 AM, Rusty Russell wrote:> On Mon, 23 Jul 2012 22:32:39 +0200, Sasha Levin <levinsasha928@gmail.com> wrote:
>> As it was discussed recently, there's currently no way for the guest to notify
>> the host about panics. Further more, there's no reasonable way to notify the
>> host of other critical events such as an OOM kill.
>
> I clearly missed the discussion.  Is this actually useful?  In practice,
> won't you want the log from the guest?  What makes a virtual guest
> different from a physical guest?

I'll try answering all of those questions:

My usecase for it is to help out with getting automatic debug output out of a problematic guest. I run a KVM tools guest which runs the trinity fuzzer within it. Once in a while, it finds something which causes the guest to misbehave (oops/panic/etc). At that point, the guest hangs there waiting for me to come and do something about it. With this device, I could automate that procedure and possibly make this entire bug hunting process fully automatic.

Now, I'm aware that this use case is probably not too common out there, but since there is a patch which tries to do the but by creating a whole new guest-host interface skipping virtio (https://lkml.org/lkml/2012/7/21/14), I guess this is useful in the real world as well.

Regarding the log, there are many ways to have that right now (good old serial/virtio-serial/etc), the issue is that I want to be notified of critical guest events and grepping the log sounds like the wrong way.

The difference between physical and virtual guest in this regard is by how much useful data I can retrieve out of a problem guest rather easily, and by things which which can occur as a result of these events (for example, add some memory if OOMs are happening frequently - which is not possible on physical hardware).

> Guest watchdog functionality might be useful, but that's simpler to
> implement via a virtio watchdog device, and more effective to implement
> via a host facility that actually pings guest functionality (rather than
> the kernel).

I agree that this echo functionality doesn't really belong in the notifier and would probably work better as a separate virtio-watchdog. Would it make sense to split this code into a virtio-notifier and virtio-watchdog?

  parent reply	other threads:[~2012-07-24 12:23 UTC|newest]

Thread overview: 16+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-07-23 20:32 [RFC 0/2] virtio: provide a way for host to monitor critical events in the device Sasha Levin
2012-07-23 20:32 ` [RFC 1/2] virtio: Introduce virtio-notifier Sasha Levin
2012-07-23 20:32 ` [RFC 2/2] kvm tools: support virtio-notifier Sasha Levin
2012-07-24  4:55 ` [RFC 0/2] virtio: provide a way for host to monitor critical events in the device Rusty Russell
2012-07-24  8:26   ` Dor Laor
2012-07-24 12:30     ` Sasha Levin
2012-07-24 12:46       ` Dor Laor
2012-07-24 13:01         ` Sasha Levin
2012-07-25  0:36           ` Rusty Russell
2012-07-25  8:46             ` Amit Shah
2012-07-24 12:23   ` Sasha Levin [this message]
2012-07-24  7:44 ` Gleb Natapov
2012-07-24 12:26   ` Sasha Levin
     [not found]   ` <500E9479.3050405@gmail.com>
2012-07-24 12:28     ` Gleb Natapov
2012-07-24 12:31       ` Sasha Levin
2012-07-24 12:33         ` Gleb Natapov

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=500E93BC.8010600@gmail.com \
    --to=levinsasha928@gmail.com \
    --cc=anthony@codemonkey.ws \
    --cc=avi@redhat.com \
    --cc=kvm@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mst@redhat.com \
    --cc=penberg@kernel.org \
    --cc=rusty@rustcorp.com.au \
    --cc=virtualization@lists.linux-foundation.org \
    --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).