[Qemu-devel] Re: A new direction for vmchannel?

[Anthony Liguori]

Chris Wright wrote:
> * Anthony Liguori (address@hidden) wrote:
>   
> > The userspace configuration aspects of the current implementation of  
> > vmchannel are pretty annoying.  Moreover, we would like to make use of  
> > something like vmchannel in a kernel driver and I fear that it's going  
> > to be difficult to do that.
> >     
>
> What's the use for vmchannel from kernel driver?
>   

Well, it doesn't exactly have to be vmchannel, but the desire is to have 
the management tools to be able to communicate directly with a kernel 
driver.  We could certainly just use virtio and route it through QEMU to 
the management tool.  It would be useful to just use vmchannel though.

> > Thoughts?
> >     
>
> Heh, works for me ;-)  Last time I suggested an fs it got shot down due to
> the burden it puts on the guest implementation (notably windows and
> other guests and ease of adding a new fs implementation).
>
> Doesn't directly solve addressing (IOW, easy to do with hierarchical
> namespace, but if vmchannel ever talks guest-to-guest...).  Clearly not
> a huge issue.
>
> Should handle the reliable messaging bit (one big push for using tcp),
> and has advantage of being a structured protocol.
>
> Has the similar ABI issue that we see in Linux with sysfs, namely it's
> easy to screw up...but that is manageable.
>
> BTW, what ever happened to just using a serial device (granted needs
> some protocol layered on top...)?
>   

I think you end up having a lot of the same issues with respect to 
making it transparent to the guest.  You could still do 9p over serial 
and still use a synthetic file system in the guest.  In fact, this is a 
pretty reasonable thing to do for older kernel guests and even Windows.

Regards,

Anthony Liguori

> thanks,
> -chris
> --
> To unsubscribe from this list: send the line "unsubscribe kvm" in
> the body of a message to address@hidden
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
>