Fixes https://bugzilla.redhat.com/show_bug.cgi?id=1628892.
The problem is that we didn't put the DRI device into the namespace for QEMU to
access, but that was only a part of the issue. The other part of the issue is
that QEMU doesn't support specifying 'rendernode' for egl-headless yet (some
patches to solve this are already upstream for 3.1, some are still waiting to
be merged). Instead, QEMU's been autoselecting the DRI device on its own.
There's no compelling reason for libvirt not doing that instead and thus
prevent any permission-related issues.

Unlike for SPICE though, I deliberately didn't add an XML attribute for users
to select the rendernode for egl-headless, because:

a) most of the time, users really don't care about which DRM node will be used
and libvirt will most probably do a good decision

b) egl-headless is only useful until we have a remote OpenGL acceleration
support within SPICE

c) for SPICE (or for SDL for that matter at some point), the rendernode is
specified as part of the <gl> subelement which says "if enabled, use OpenGL
acceleration", but egl-headless graphics type essentially serves the same
purpose, it's like having <gl enabled='yes'/> for SPICE, thus having a <gl>
subelement for egl-headless type is rather confusing

Erik Skultety (12):
  util: Introduce virHostGetDRMRenderNode helper
  qemu: command: spice: Pick the first available DRM render node
  qemu: caps: Start probing for egl-headless display type
  qemu: caps: Introduce QEMU_EGL_HEADLESS_RENDERNODE capability
  qemu: command: Introduce qemuBuildGraphicsEGLHeadlessCommandLine
    helper
  conf: Add egl-headless to virDomainGraphicsDef union
  qemu: domain: Put the egl-headless' rendernode device into the
    namespace
  qemu: cgroup: Add the DRI device to the cgroup list for egl-headless
    too
  command: Put the 'rendernode' option onto egl-headless graphics
    cmdline
  security: dac: Relabel the DRI render device for  egl-headless too
  tests: Add a test case for the egl-headless' rendernode option
  docs: Provide a news update for libvirt being able to pick a DRI
    device

 docs/news.xml                                 | 13 ++++
 src/conf/domain_conf.h                        |  3 +
 src/libvirt_private.syms                      |  1 +
 src/qemu/qemu_capabilities.c                  | 17 +++--
 src/qemu/qemu_capabilities.h                  |  1 +
 src/qemu/qemu_cgroup.c                        | 15 ++--
 src/qemu/qemu_command.c                       | 72 +++++++++++++++----
 src/qemu/qemu_domain.c                        | 15 ++--
 src/security/security_dac.c                   | 21 +++---
 src/util/virutil.c                            | 53 ++++++++++++++
 src/util/virutil.h                            |  2 +
 ...cs-egl-headless-rendernode-autoselect.args | 26 +++++++
 ...ics-egl-headless-rendernode-autoselect.xml |  1 +
 tests/qemuxml2argvmock.c                      |  9 +++
 tests/qemuxml2argvtest.c                      |  4 ++
 15 files changed, 220 insertions(+), 33 deletions(-)
 create mode 100644 tests/qemuxml2argvdata/graphics-egl-headless-rendernode-autoselect.args
 create mode 120000 tests/qemuxml2argvdata/graphics-egl-headless-rendernode-autoselect.xml

--
2.19.1

--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list

On Thu, Nov 22, 2018 at 05:35:58PM +0100, Erik Skultety wrote:
>Fixes https://bugzilla.redhat.com/show_bug.cgi?id=1628892.
>The problem is that we didn't put the DRI device into the namespace for QEMU to
>access, but that was only a part of the issue. The other part of the issue is
>that QEMU doesn't support specifying 'rendernode' for egl-headless yet (some
>patches to solve this are already upstream for 3.1, some are still waiting to
>be merged). Instead, QEMU's been autoselecting the DRI device on its own.
>There's no compelling reason for libvirt not doing that instead and thus
>prevent any permission-related issues.
>
>Unlike for SPICE though, I deliberately didn't add an XML attribute for users
>to select the rendernode for egl-headless, because:
>
>a) most of the time, users really don't care about which DRM node will be used
>and libvirt will most probably do a good decision
>

Picking a default does not conflict with displaying it in live XML.

>b) egl-headless is only useful until we have a remote OpenGL acceleration
>support within SPICE
>
>c) for SPICE (or for SDL for that matter at some point), the rendernode is
>specified as part of the <gl> subelement which says "if enabled, use OpenGL
>acceleration", but egl-headless graphics type essentially serves the same
>purpose, it's like having <gl enabled='yes'/> for SPICE, thus having a <gl>
>subelement for egl-headless type is rather confusing

Could be just <gl rendernode=''/>

Even if its usefulness is short-lived, not exposing this knob of the
domain while we do expose it for SPICE feels wrong.

Jano
--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list