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. >> An inherently reliable socket transport solves the above problem >> while keeping things simple. Note, this is not a new concept. There >> is already an AF_IUCV for s390. VMware is also developing an AF_VMCI >> socket family. >> > > The trouble is that it presumes that the host and guest (or whoever > the endpoints are) are on the same physical machine and will remain > that way. Given that live migration is a feature that people seem to > like, then you'd end up needing to transport this protocol over a real > network anyway - and at that point you may as well use proper > TCP/IP. The alternative is to say either "if you use this feature > you can't migrate, and you can only resume on the same host", or "you > can use this feature, and we'll work out a global namespace and proxy > it over TCP for you". Neither seems very satisfactory. 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. 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.). 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. Regards, Anthony Liguori > J _______________________________________________ Virtualization mailing list Virtualization@lists.linux-foundation.org https://lists.linux-foundation.org/mailman/listinfo/virtualization
