Re: [RFC 0/2] virtio: provide a way for host to monitor critical events in the device

[Amit Shah <amit.shah@redhat.com>]

On (Wed) 25 Jul 2012 [10:06:37], Rusty Russell wrote:
> On Tue, 24 Jul 2012 15:01:59 +0200, Sasha Levin <levinsasha928@gmail.com> wrote:
> > virtio on it's own was introduced to help solve the fragmentation
> > around virtualized devices, so I don't think that the main purpose of
> > doing virtio drivers is due to any performance benefits virtio may
> > provide.
> 
> There's one argument in your favor (with my Linaro hat on): ARM wants a
> virtio reboot button, which would look remarkably similar.  There's no
> standard ARM hardware for this.
> 
> So a more generalized virtio-event device might make sense.  But there
> are almost an infinite number of guest events we might want: panics,
> oom, low memory, stuck devices, deadlock, etc, etc.  I'm concerned about
> trying to standardize them.  If we include a unspecified free-form
> string, people will end up relying on the contents.  If we add a feature
> bit for every new event, we'll end up running out of feature bits :)
> 
> CC'ing Amit for opinion over how much of this should be done via
> virtio-serial.

The prevoius discussion happend on kvm-devel; it was suggested then to
use virtio-serial for that as well.  We don't have an in-kernel
interface for communication yet (barring the console interface, which
we don't want to re-use for other reasons).

Writing the in-kernel interface for communication with the host is not
too much work as well.

I agree using virtio-serial for several such free-form message-passing
between the guest and host is the right way to implement such stuff.

The lack of dedicated devices over either virtio or emulation of
real hardware can be overcome by adding some documentation -
preferably to the virtio spec's appendix, showing how watchdogs, etc.,
are implemented using virtio-serial.

		Amit