On (Wed) 25 Jul 2012 [10:06:37], Rusty Russell wrote: > On Tue, 24 Jul 2012 15:01:59 +0200, Sasha Levin <levinsasha928@xxxxxxxxx> 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 -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
