Current TW (host and guest) using:

<video>
  <model type='virtio' heads='1' primary='yes'>
    <acceleration accel3d='yes'/>
</model>

<graphics type='spice'>
  <listen type='none'/>
  <gl enable='yes' rendernode='/dev/dri/by-path/pci-0000:03:00.0-render'/>
</graphics>

The qemu process (launched normally through libvirt) becomes a zombie process.

Recent mesa includes a disk shader cache. It uses a thread job queue with low
priority, set with sched_setscheduler(SCHED_IDLE). However, that syscall is
rejected by the "resourcecontrol" seccomp qemu filter. "resourcecontrol=deny"
is in the default command line of libvirt when launching a qemu VM.

Example strace for simplified qemu command line:
strace qemu-system-x86_64 -sandbox on,resourcecontrol=deny  -spice gl=on
[...]
openat(AT_FDCWD, "/home/user/.cache/mesa_shader_cache/index",
O_RDWR|O_CREAT|O_CLOEXEC, 0644) = 14
sched_setscheduler(15979, SCHED_IDLE, [0]) = ?

The fix is in qemu upstream:

commit 056de1e894155fbb99e7b43c1c4382d4920cf437
Author: Marc-Andr� Lureau <marcandre.lureau@redhat.com>
Date:   Tue Jul 10 16:55:57 2018 +0200

    seccomp: allow sched_setscheduler() with SCHED_IDLE policy
    Current and upcoming mesa releases rely on a shader disk cash. It uses
    a thread job queue with low priority, set with
    sched_setscheduler(SCHED_IDLE). However, that syscall is rejected by
    the "resourcecontrol" seccomp qemu filter.

    Since it should be safe to allow lowering thread priority, let's allow
    scheduling thread to idle policy.
    [...]


I have tested the patch on current openSUSE:Factory qemu and it fixes the
issue.