Remote doesn't work in QEMU

[cjfh]

Running glxgears on native ARM:

Terminal 1:

root@linaro-alip:~# libgl_remote 1
remote_serve 1
libGL: built on Apr 10 2017 15:51:48
libGL:loaded: libGLESv1_CM.so
libGL:loaded: libEGL.so

Terminal 2:

root@linaro-alip:~# glxgears
libGL:loaded: libGLESv1_CM.so
libGL:loaded: libEGL.so
libGL: built on Apr 10 2017 15:51:48
libGL: pipe='1'
libGL: remote pid 1
1241 frames in 5.0 seconds = 248.120 FPS

Running glxgears in a QEMU i386 chroot, without running libgl_remote on ARM host:

connect: Connection refused
libGL:loaded: libGLESv1_CM.so.1
libGL:loaded: libEGL.so.1
libGL: built on Apr 10 2017 15:36:05
qemu: uncaught target signal 6 (Aborted) - core dumped

Running glxgears in a QEMU i386 chroot, running libgl_remote on the ARM host:

Terminal 1 (native ARM):

root@linaro-alip:~# libgl_remote 1
remote_serve 1
server: mapping failed from shm '/glshim.0'
server handshake: No such file or directory
Error doing server handshake.
Error during remote_serve().

Terminal 2 (QEMU i386 chroot):

libGL: pipe='1'
warning: both sides waiting? (repeat a few thousand times)

libgl_remote /glshim.0 doesn't work:

root@linaro-alip:~# libgl_remote /glshim.0
remote_serve /glshim.0
connect: Address already in use
Error during remote_serve().

[lunixbochs]

Reboot, reproduce the i386 QEMU chroot error, and post a log of every shell command you ran during repro. What you've posted isn't enough of a reproduction case. Where did you get the libgl_remote 1 command? I've never posted that anywhere. Are you using NOSPAWN? The default mode of libgl remote requires the host command to be executable (it works better with qemu-user LD_PATH than with a full chroot, which is easy to invoke), and the alternate launch mode requires multiple environment variables iirc.

Remote was developed for QEMU and Exagear and tested against both as well as native on both arm and x86.

For Address already in use, try running strace -ff libgl_remote /glshim.0. That error implies you already bound to the SHM (likely because another libgl_remote is running)

[lunixbochs]

Also, make sure the SHM directories are mapped into the chroot - try mount --bind with /dev/shm into the chroot (will need to repeat each boot). The file path is a pipe used for synchronization (like a semaphore), while the SHM is used for the actual data transfer.

[cjfh]

The default mode of libgl remote requires the host command to be executable (it works better with qemu-user LD_PATH than with a full chroot, which is easy to invoke), and the alternate launch mode requires multiple environment variables iirc.

Yeah, that's probably the problem. I ran i386 glxgears just fine using qemu-i386-static outside of a chroot, but it didn't work in the chroot.

[lunixbochs]

My guess is SHM namespaces then. Try the bind mount from my previous comment, or if your /dev/shm is a symlink to /run or /var/run, try mounting that.

[lunixbochs]

did that fix it?

[cjfh]

Yes.