[libvirt] [PATCH 2/2] qemu_cgroup: allow access to /dev/dri/render*

Gerd Hoffmann kraxel at redhat.com
Thu May 19 14:12:52 UTC 2016


> $ ls -lZ /dev/dri/
> total 0
> crw-rw----+ 1 root video system_u:object_r:dri_device_t:s0 226,   0 May 18
> 19:17 card0
> crw-------. 1 root video system_u:object_r:dri_device_t:s0 226,  64 May 18
> 19:17 controlD64
> crw-rw----+ 1 root video system_u:object_r:dri_device_t:s0 226, 128 May 18
> 19:17 renderD128
> qemu itself loops over /dev/dri, grabs the first matching renderD* that it can
> open, then does its magic. Some questions I have in general:
> - is there only ever one render node? or one per video card?

One per video card.

> - is it okay to use the same node for multiple VMs simultaneously?


> Maybe the long term fix is to have libvirt pass in a pre-opened fd for
> qemu:///system, since I don't know if it would be acceptable to chown
> qemu:qemu on the render node, but maybe we use setfacl instead.

chown isn't a good idea I think.  But doesn't use libvirt setfacl anyway
for simliar things (i.e. /dev/bus/usb/... for usb pass-through) ?

> I certainly agree with that at least WRT UI tools... after playing with this
> stuff a bit I won't be adding UI clicky 'enable gl' in virt-manager in the
> short term, there's just too many operational caveats. But advertisement in
> the form of blog posts with all the caveats listed will probably save us bug
> reports, and maybe a command line virt-xml one liner to turn it on for an
> existing VM. And of course have virt-manager work with it correctly on the
> viewer side, patches in git and fedora build coming soon

Agree, we should first get things going smooth before adding a big
"enable gl" switch in the UI.


More information about the libvir-list mailing list