I recently discovered the vsock-support of xpra and tested it succesfully as described here: #983
Kvm also provides a shared memory device, but there does not seem to be a possibility to enable xpra's mmap-support when using --bind-vsock (or --bind-tcp).
My xpra version is:
The Linux distribution I use on the host and in the guest is Fedora 25.
The shared memory device in kvm called ivshmem was configured as follows:
sudo dnf install ivshmem-tools
ls -la /dev/shm/ivshmem
sudo /usr/bin/qemu-system-x86_64 -enable-kvm -machine type=pc,accel=kvm -m 4096 -name Fedora-25 -drive file=/var/lib/libvirt/images/fedora25.img,if=virtio,index=0,format=raw -smp 4,sockets=1,cores=2,threads=2 -net nic -net user -cpu host -chardev socket,path=/tmp/ivshmem_socket,id=nahanni -device ivshmem-doorbell,chardev=nahanni
sudo dnf install kernel-devel
sudo dnf update kernel
git clone https://gitorious.org/nahanni/guest-code.git
sudo make install
sudo modprobe uio
sudo insmod /lib/modules/4.8.15300.fc25.x86_64/kernel/drivers/uio/uio_ivshmem.ko
ls -la /dev/uio0
It would be nice to use the shared memory device in order to have fast, secure and seamless sandboxes with kvm and xpra. That way every distribution running kvm would be able to provide a secure context for applications like Qubes OS does.
Also that would probably be one of the best Christmas presents for all the paranoid people out there also wanting to use grsecurity with their virtualization setups.
(made some minor edits to the description - also tested with Fedora 25 at both ends)
/tmp/ivshmem_socketis left behind, the
ivshmem-servercommand will fail with "cannot bind". (run with
-v -Fto get more details, then just remove the file if unused)
depmod -a;modprobe uio_ivshmem
/dev/uio0file) and I get "Invalid argument" every single time.. The only code example that does not fail is "writedump" but this accesses the file as a file, not as shared memory. What am I missing?
Hi Antoine, I did some research. Considering reading and writing to the mmap file:
While being in the VM, do _not_ load the uio modules. Instead try the following:
00:04:0 RAM memory: Red Hat, Inc Inter-VM shared memory (rev 01)
echo 1 > /sys/devices/pci0000\:00/0000\:00\:04.0/enable
#!/usr/bin/python import sys import mmap with open(sys.argv,"r+") as f: map = mmap.mmap(f.fileno(), 0) print map.readline() map.close()
Does this help or do the problems persist?
I had to rmmod
uio_ivshmem so that the "enable" flag showed "0".
After that, I enabled it with echo and I can connect with xpra and mmap!
(we're going to need a few minor patches to make things work - nothing major)
The only problem that I have is the size of the mmap area: it ended up the right size (256MB) on the host (probably after the client tried to write the token near the 256MB mark) but the guest only sees about 4MB. How do we control the size of this mmap area?
workarounds for the small ivshmem size
Here's what you need to use ivshmem with xpra:
To use it:
xpra start --bind-tcp=0.0.0.0: --no-daemon --start=xterm -d mmap \ --mmap=/sys/devices/pci0000:00/0000:00:04.0/resource2
xpra attach tcp:GUEST:14500 --mmap=/dev/shm/ivshmem -d mmap -d draw
FWIW: I tried running the client in the guest instead, but writing to the mmap area failed with "Input / Output error", does the host side need to initiate things perhaps?
Thank you very much! This works great. I can confirm, that this works for "--bind-tcp" and also for "--bind-vsock" for host to guest connections.
I'll check on the other issues in a few days.
sudo /usr/bin/qemu-system-x86_64 -enable-kvm -machine type=pc,accel=kvm -m 4096 \ -name Fedora-25 -drive file=/var/lib/libvirt/images/fedora25.img,if=virtio,index=0,format=raw \ -smp 4,sockets=1,cores=2,threads=2 -net nic -net user -cpu host \ -object memory-backend-file,id=mb1,size=256M,share,mem-path=/dev/shm/ivshmem \ -device ivshmem-plain,id=ivshm-plain,memdev=mb1
sudo ivshmem-server -l 256M
Hah, changing the size is easy.
I don't think there's anything left to do on this ticket so I'm closing it, feel free to re-open if I've missed something.
this ticket has been moved to: https://github.com/Xpra-org/xpra/issues/1387