On (Wed) 25 Jul 2012 [10:06:37], Rusty Russell wrote:

On Tue, 24 Jul 2012 15:01:59 +0200, Sasha Levin [off-list ref] wrote:

quoted

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