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

Alexander Graf
2009-01-24T10:22:11Z

On 24.01.2009, at 01:02, Dor Laor <dlaor@redhat.com> 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?

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 majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html