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

[Dor Laor]

Alexander Graf wrote:
> On 24.01.2009, at 01:02, Dor Laor <address@hidden> wrote:
>
> > Anthony Liguori wrote:
> > > Gleb Natapov wrote:
> > > > On Fri, Jan 23, 2009 at 08:45:33AM -0600, Anthony Liguori wrote:
> > > >
> > > > > Thoughts?
> > > > Looks good, but I am not to much familiar with p9. Will it provide us
> > > > with stream semantics?
> > >
> > > Sure.  It has read and write operations.  You just have to implement 
> > > them in the same sort of way you'd implement them for a character 
> > > device.
> >
> > So why not having a virtio pv-serial device.
> > Above this device/driver users can have several 
> > implementations/semantics:
> >   - raw messages
> >   - 9p
> >   - userspace tcp/ip
> >      - We already used the host part of it.
> >      - It provides reliability and handles migration too.
> >      - Since its userspace, there is no routing/addressing involved.
> > The above will make windows and other OSs happy and users can still 
> > get 9p or tcp or raw.
> > Maybe even the virtio console can be based over it (Don't really know 
> > nothing about it )
>
> I don't see where there's any benefit here. You need a driver in the 
> guest for virtio either way - and what exactly goes to userspace ( fs 
> or datagram protocol ) is an implementation detail, no?
There are two benefits:
a. Simplify the kernel driver over virtio.
   It does not need to implement 9p interface (important for non Linux) 
or other.
   It would be also possible to use the serial as a medium, so no 
driver at all.
b. Flexibility - you're not bound to a specific solution.
   One can use userspace tcp/ip over it, others will use 9p (which is 
nice), etc.

IMO if the current 9p is mature and supports stream based poll semantics 
like was discussed, and is not too
complex for Windows to implement we can use 9p.
Otherwise, let's go for a generic solution like pv serial using virtio.

- dor

> Alex
>
> > btw: I do suggest to keep the former work of nic based vmchannel. 
> > Except for the cmdline,
> > every thing else is committed. It might be good for older OSs and 
> > just work out of the box.
> >
> >
> > > > How much work is needed to support this in
> > > > Windows (what is your estimation)?
> > >
> > > If you structure your guest applications to use a library, sort of 
> > > like libsysfs, then on Windows, you could implement a 9P client in 
> > > userspace.  I have a 9P client that can be used for this.  You just 
> > > need some way to get the stream to userspace.  You could write a 
> > > virtio windows driver that exposed the stream down to userspace.  
> > > You could also use an alternative transport for Windows (like a 
> > > serial port).
> > >
> > > > Will migration be transparent to
> > > > in guest users?
> > >
> > > There's no better migration story for vmchannel backends implemented 
> > > outside of QEMU.  For the ones in QEMU, migration should be 
> > > transparent.
> > >
> > > Regards,
> > >
> > > Anthony Liguori
> > >
> > > > --
> > > >            Gleb.
> >
> > --
> > 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
> --
> 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