[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]

Re: [libvirt] [PATCH] qemu: Allow /dev/dri/renderD128



On Wed, Feb 08, 2017 at 11:28:33AM +0100, Michal Privoznik wrote:
> On 02/08/2017 11:16 AM, Daniel P. Berrange wrote:
> > On Wed, Feb 08, 2017 at 10:44:53AM +0100, Michal Privoznik wrote:
> >> On 02/08/2017 10:31 AM, Daniel P. Berrange wrote:
> >>> On Wed, Feb 08, 2017 at 10:26:26AM +0100, Michal Privoznik wrote:
> >>>> This demand comes from qemu_egl_rendernode_open() in qemu source
> >>>> code. It is needed for virgl to work with qemu:///system
> >>>> connection. The session one works just fine.
> >>>>
> >>>> Signed-off-by: Michal Privoznik <mprivozn redhat com>
> >>>> ---
> >>>>  docs/drvqemu.html.in               | 1 +
> >>>>  src/qemu/qemu.conf                 | 3 ++-
> >>>>  src/qemu/qemu_cgroup.c             | 1 +
> >>>>  src/qemu/test_libvirtd_qemu.aug.in | 1 +
> >>>>  4 files changed, 5 insertions(+), 1 deletion(-)
> >>>
> >>>> diff --git a/src/qemu/qemu_cgroup.c b/src/qemu/qemu_cgroup.c
> >>>> index 6c90d46d1..b47f714fc 100644
> >>>> --- a/src/qemu/qemu_cgroup.c
> >>>> +++ b/src/qemu/qemu_cgroup.c
> >>>> @@ -47,6 +47,7 @@ const char *const defaultDeviceACL[] = {
> >>>>      "/dev/random", "/dev/urandom",
> >>>>      "/dev/ptmx", "/dev/kvm", "/dev/kqemu",
> >>>>      "/dev/rtc", "/dev/hpet", "/dev/vfio/vfio",
> >>>> +    "/dev/dri/renderD128",
> >>>
> >>> Surely this is only needed in very specific scenarios. ie with
> >>> the virtio-vga 3d rendering enabled.
> >>>
> >>> Allowing unconditional access to the DRI devices is a big
> >>> wide open door from security POV, for something few VMs
> >>> will ever need.
> >>>
> >>> The global device whitelist is only for devices that we
> >>> expect every QEMU to unconditionally require.
> >>
> >> I can argue the same about /dev/vfio/vfio and yet we have it on the list.
> > 
> > I consider that to be a bug we should fix too. It should only ever have
> > been added if the guest is actually using vfio.
> 
> Agreed. So just to be clear on the design, if we automatically enable
> /dev/vfio/vfio in devices cgroup on domain startup (of course only for
> domains that are doing pci passtrhough^Wassignment), you would be okay
> with that?

We'd need to actually check the PCI device config to see if it
is set to use vfio or the legacy impl or the default, so slightly
more complex, but yes to the general principle.

Also might need updating on hotplug/unplug.

> Similarly, allowing /dev/dri/renderD128 for domains with virgl on their
> startup.

Yep

Regards,
Daniel
-- 
|: http://berrange.com      -o-    http://www.flickr.com/photos/dberrange/ :|
|: http://libvirt.org              -o-             http://virt-manager.org :|
|: http://entangle-photo.org       -o-    http://search.cpan.org/~danberr/ :|


[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]