Anthony Liguori wrote:
> Jeremy Fitzhardinge wrote:
>
>>> Each of these sockets are going to be connected to a backend (to
>>> implement guest<=>copy/paste for instance). We want to implement
>>> those backends in userspace and preferably in QEMU.
>>>
>>> Using some raw protocol over ethernet means you don't have
>>> reliability. If you use a protocol to get reliability (like TCP),
>>> you now have to implement a full TCP/IP stack in userspace or get the
>>> host kernel involved. I'd rather not get the host kernel involved
>>> from a security perspective.
>>>
>>>
>> There's nothing wrong with user-mode TCP, or you could run your TCP
>> stack in a special-purpose guest if you're really paranoid.
>>
>
> That seems unnecessarily complex.
>
Well, the simplest thing is to let the host TCP stack do TCP. Could you
go into more detail about why you'd want to avoid that?
> This is why I've been pushing for the backends to be implemented in
> QEMU. Then QEMU can marshal the backend-specific state and transfer it
> during live migration. For something like copy/paste, this is obvious
> (the clipboard state). A general command interface is probably
> stateless so it's a nop.
>
Copy/paste seems like a particularly bogus example. Surely this isn't a
sensible way to implement it?
> I'm not a fan of having external backends to QEMU for the very reasons
> you outline above. You cannot marshal the state of a channel we know
> nothing about. We're really just talking about extending virtio in a
> guest down to userspace so that we can implement paravirtual device
> drivers in guest userspace. This may be an X graphics driver, a mouse
> driver, copy/paste, remote shutdown, etc.
>
> A socket seems like a natural choice. If that's wrong, then we can
> explore other options (like a char device, virtual fs, etc.).
I think a socket is a pretty poor choice. It's too low level, and it
only really makes sense for streaming data, not for data storage
(name/value pairs). It means that everyone ends up making up their own
serializations. A filesystem view with notifications seems to be a
better match for the use-cases you mention (aside from cut/paste), with
a single well-defined way to serialize onto any given channel. Each
"file" may well have an application-specific content, but in general
that's going to be something pretty simple.
> This
> shouldn't be confused with networking though and all the talk of doing
> silly things like streaming fence traffic through it just encourages the
> confusion.
I'm not sure what you're referring to here.
J
_______________________________________________
Virtualization mailing list
[email protected]
https://lists.linux-foundation.org/mailman/listinfo/virtualization
