Re: [libvirt] [PATCH 2/2] qemu_cgroup: allow access to /dev/dri/render*
On Thu, May 19, 2016 at 04:12:52PM +0200, Gerd Hoffmann wrote:
Hi,
> $ 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 there a way to tell QEMU which video card to use ? If so we need to
somehow represent this in libvirt.
> - is it okay to use the same node for multiple VMs
simultaneously?
Yes.
Presumably they're going to compete for execution time and potentially
VRAM at least ? I assume they have 100% security isolation from each
other though. IOW, permissioning is really just there to prevent a
rogue processes from doing denial of service on the GPU resources,
rather than actively compromising other users of the GPU ?
> 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) ?
No, we exclusively switch access to QEMU only.
Obviously the DRI stuff is different as we expected the host OS to
have continued concurrent use of the video card.
Regards,
Daniel
--
|: http://berrange.com -o- http://www.flickr.com/photos/dberrange/ :|
|: http://libvirt.org -o- http://virt-manager.org :|
|: http://autobuild.org -o- http://search.cpan.org/~danberr/ :|
|: http://entangle-photo.org -o- http://live.gnome.org/gtk-vnc :|