[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <500E93BC.8010600@gmail.com>
Date: Tue, 24 Jul 2012 14:23:24 +0200
From: Sasha Levin <levinsasha928@...il.com>
To: Rusty Russell <rusty@...tcorp.com.au>
CC: mst@...hat.com, penberg@...nel.org, asias.hejun@...il.com,
virtualization@...ts.linux-foundation.org,
linux-kernel@...r.kernel.org, kvm@...r.kernel.org, avi@...hat.com,
anthony@...emonkey.ws, wency@...fujitsu.com
Subject: Re: [RFC 0/2] virtio: provide a way for host to monitor critical
events in the device
On 07/24/2012 06:55 AM, Rusty Russell wrote:> On Mon, 23 Jul 2012 22:32:39 +0200, Sasha Levin <levinsasha928@...il.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?
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists