-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 (snip) > The patches are on the list (latest version sent last week): > http://comments.gmane.org/gmane.linux.kernel.virtualization/27455 > > They are only "Request For Comments" because the VIRTIO > specification changes have not been approved yet. Once the spec > is approved then the patches can be seriously considered for > merging. > > There will definitely be a v6 with Claudio Imbrenda's locking > fixes. If that's any help, feel free to CC me and we'll test it. (not sure how long I will stay subscribed to this high traffic list)
>> We now have a vsock transport merged into xpra, which works very >> well with the kernel and qemu versions found here: >> http://qemu-project.org/Features/VirtioVsock Congratulations on >> making this easy to use! Is the upcoming revised interface >> likely to cause incompatibilities with existing binaries? > > Userspace applications should not notice a difference. Great. >> It seems impossible for the host to connect to a guest: the >> guest has to initiate the connection. Is this a feature / known >> limitation or am I missing something? For some of our use cases, >> it would be more practical to connect in the other direction. > > host->guest connections have always been allowed. I just checked > that it works with the latest code in my repo: > > guest# nc-vsock -l 1234 host# nc-vsock 3 1234 Sorry about that, it does work fine, I must have tested it wrong. With our latest code: * host connecting to a guest session: guest# xpra start --bind-vsock=auto:1234 --start-child=xterm host# xpra attach vsock:$THECID:1234 * guest out to the host (no need for knowing the CID): host# xpra start --bind-vsock=auto:1234 --start-child=xterm guest# xpra attach vsock:host:1234 >> In terms of raw performance, I am getting about 10Gbps on an >> Intel Skylake i7 (the data stream arrives from the OS socket >> recv syscall split into 256KB chunks), that's good but not much >> faster than virtio-net and since the packets are avoiding all >> sorts of OS layer overheads I was hoping to get a little bit >> closer to the ~200Gbps memory bandwidth that this CPU+RAM are >> capable of. Am I dreaming or just doing it wrong? > > virtio-vsock is not yet optimized but the priority is not to make > something faster than virtio-net. virtio-vsock is not for > applications who are trying to squeeze out every last drop of > performance. Instead the goal is to have a transport for > guest<->hypervisor services that need to be zero-configuration. Understood. It does that and this is a big win for us already, it's also faster than virtio-net it seems, so this was not a complaint. >> How hard would it be to introduce a virtio mmap-like transport >> of some sort so that the guest and host could share some memory >> region? I assume this would give us the best possible >> performance when transferring large amounts of data? (we already >> have a local mmap transport we could adapt) > > Shared memory is beyond the scope of virtio-vsock and it's > unlikely to be added. I wasn't thinking of adding this to virtio-vsock, this would be a separate backend. > There are a few existing ways to achieve that without involving > virtio-vsock: vhost-user or ivshmem. Yes, I've looked at those and they seem a bit overkill for what we want to achieve. We don't want sharing with multiple guests, or interrupts. All we want is a chunk of host memory to be accessible from the guest.. Thanks Antoine -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iEYEARECAAYFAlcLkBsACgkQGK2zHPGK1ruJ0wCfbNkc5L0ewUBuI7DgTyuwGRBz aZoAn2pEbrVAkLoCMOunCYQ1FoaDIETr =qrz1 -----END PGP SIGNATURE-----
