[Buildroot] [PATCH RESEND v5 5/5] package/qemu: add virglrenderer support
Romain Naour
romain.naour at smile.fr
Thu May 14 18:38:26 UTC 2026
Hello Joseph,
Le 14/05/2026 à 20:05, Joseph Kogut a écrit :
> Hello Romain,
>
> On Thu, May 14, 2026 at 5:10 AM Romain Naour <romain.naour at smile.fr> wrote:
>>
>> Le 14/05/2026 à 00:09, Joseph Kogut a écrit :
>>>
>>> To answer your question succinctly, selecting virglrenderer without
>>> virgl still leaves Venus and DRM drivers, and any combination of these
>>> can provide the guest with graphics and compute capabilities. Building
>>> virglrenderer without virgl, venus, or DRM probably (?) results in a
>>> qemu build that works as expected, but lacks graphics/compute for
>>> guests.
>>
>> Indeed, virglrenderer build (at least) without any virgl, venus, or DRM (this
>> case may be non-functional though):
>>
>> virglrenderer 1.3.0
>>
>> Directories
>> prefix : /usr
>> libdir : lib
>>
>> Configuration
>> c_args : -D_LARGEFILE_SOURCE -D_LARGEFILE64_SOURCE
>> -D_FILE_OFFSET_BITS=64 -O2 -g0 -D_FORTIFY_SOURCE=1
>> egl : false
>> glx : false
>> gbm : false
>> venus : false
>> drm-amdgpu : false
>> drm-asahi : false
>> drm-i915 : false
>> drm-panfrost : false
>> drm-msm : false
>> render server worker : none
>> video : false
>> tests : false
>> fuzzer : false
>> tracing : none
>> unstable-apis : false
>>
>> Even if it will prevent any use of graphics/compute for Qemu guests.
>>
>>>
>>> We turn on VirGL by default when the host has libGL, and likewise turn
>>> on Venus by default when a mesa Vulkan driver is enabled. We also turn
>>> on DRM backends by default when their corresponding UMDs are selected,
>>> more on that below.
>>
>> I'm agree with that but using "default y if" still allows the user to disable
>> the option (because it's an user visible kconfig option):
>>
>> config BR2_PACKAGE_VIRGLRENDERER_VIRGL
>> bool "virgl"
>> default y
>>
>> I'm tkinking about this case for the sake of our autobuilder testing that can
>> select or disable randomly any kconfig option when it generate the defconfig to
>> build.
>>
>
> Having the ability to disable VirGL and Venus is likely quite
> desirable, when a DRM backend is available. VirGL/Venus and host
> native context both provide paths to accelerated OpenGL/Vulkan, but
> host native context has lower overhead, better security, more complete
> API support, and additional support for OpenCL and VAAPI for hardware
> accelerated video encode/decode. There's even a merge request open in
> the virglrenderer repository to support ROCm in guests [0].
Ok.
>
>> I guess you could try using hidden options like for waffle package:
>>
>> https://gitlab.com/buildroot.org/buildroot/-/blob/master/package/waffle/Config.in?ref_type=heads
>>
>> (draft):
>>
>> config BR2_PACKAGE_VIRGLRENDERER_SUPPORTS_VIRGL
>> bool
>> default y if (BR2_PACKAGE_HAS_LIBEGL && BR2_PACKAGE_HAS_LIBGBM) \
>> || BR2_PACKAGE_HAS_LIBGL
>>
>> config BR2_PACKAGE_VIRGLRENDERER
>> bool "virglrenderer"
>> depends on BR2_TOOLCHAIN_GCC_AT_LEAST_4_9
>> depends on BR2_TOOLCHAIN_HAS_THREADS
>> depends on BR2_USE_MMU # fork()
>> select BR2_PACKAGE_LIBEPOXY
>> help
>>
>> We can actually get ride of BR2_PACKAGE_VIRGLRENDERER_VIRGL option:
>>
>> ifeq ($(BR2_PACKAGE_VIRGLRENDERER_SUPPORTS_VIRGL),y)
>> ifeq ($(BR2_PACKAGE_HAS_LIBEGL)$(BR2_PACKAGE_HAS_LIBGBM),yy)
>> VIRGLRENDERER_PLATFORMS += egl
>> VIRGLRENDERER_DEPENDENCIES += libegl \
>> libgbm
>> endif
>>
>> ifeq ($(BR2_PACKAGE_HAS_LIBGL),y)
>> VIRGLRENDERER_PLATFORMS += glx
>> VIRGLRENDERER_DEPENDENCIES += libgl
>> endif
>> endif # BR2_PACKAGE_VIRGLRENDERER_SUPPORTS_VIRGL
>>
>> Or do you want let the user the hability to disable virglrenderer virgl support
>> evenf if EGL or GL is available?
>
> If a user knows their KMD is a supported host native context path,
> they may wish to disable API forwarding (VirGL/Venus) to reduce code
> size and/or prevent less secure paths from being available.
>
> For example, if a guest has a mesa build that lacks host native
> context virtio backends, but includes the virgl/venus UMDs, that guest
> gets access to running untrusted code in the host UMD, which opens up
> numerous potential exploits and VM escapes.
>
> Disabling API forwarding in virglrenderer means guests must run their
> own host native context UMD inside the guest address space, which
> talks to the host kernel's DRM API through virglrenderer over
> virtio-gpu. Without this, they get no graphics or compute capability,
> no fallback to API forwarding. This removes the host's Mesa build from
> the attack surface, in addition to being faster and more featured.
Ok.
>
>>>
>>>>>
>>>>> Perhaps we could clarify this by expanding the help message under
>>>>> qemu's virglrenderer config to explain that virglrenderer itself has
>>>>> additional options.
>>>>
>>>> First, we should improve the libepoxy help text to explain why it's fine to use
>>>> libepoxy without EGL and GL.
>>>
>>> That's a reasonable next step.
>>>
>>>> Then, BR2_PACKAGE_QEMU_VIRGLRENDERER should not only select
>>>> BR2_PACKAGE_VIRGLRENDERER without enabling any suboption.
>>>>
>>>
>>> This is a bit tricky. Earlier versions in this series attempted to
>>> implicitly enable virglrenderer DRM backends based on the presence of
>>> a Mesa UMD, the consumer of the DRM API. So if we had
>>> BR2_PACKAGE_MESA3D_GALLIUM_DRIVER_RADEONSI or
>>> BR2_PACKAGE_MESA3D_VULKAN_DRIVER_AMD, we would enable the amdgpu DRM
>>> backend in virglrenderer.
>>>
>>> The initial assumption was that having these UMDs enabled implies we
>>> also have the corresponding KMD. However, I realized that another very
>>> valid config is to have no UMD enabled on the host, in which case we
>>> need an explicit config to enable the DRM backend for virglrenderer.
>>> This works in coordination with a mesa config to enable virtio as a
>>> backend for various UMDs, which is part of a separate series [1] (This
>>> mesa build is intended to run in a guest environment).
>>
>> Please, try to add a comment (in help or .mk direclty) about such "valid corner
>> use case".
>>
>
> I'll add this to the next submission.
>
>>>
>>> I'm open to thoughts and ideas on the best way to handle this.
>>
>> I'm not sure about virglrenderer DRM backends being enabled based on the
>> presence of a Mesa UMD. If only the user can know if a specific virglrenderer
>> DRM backend can be enabled or not, we can't do much.
>>
>> At least we could add a comment in Config.in when no suboption is selected
>>
>> For example, if busybox package is disabled a comment is printed in menuconfig:
>>
>> comment "You may need to enable other packages to get a working system"
>> comment "You better know what you're doing!"
>>
>> https://gitlab.com/buildroot.org/buildroot/-/blob/master/package/busybox/Config.in?ref_type=heads#L101
>>
>> comment "You may need to enable virgl or venus or a DRM backend to get a working
>> graphics compute for guests"
>> depends on !BR2_PACKAGE_VIRGLRENDERER_VIRGL \
>> && !BR2_PACKAGE_VIRGLRENDERER_VENUS \
>> && !BR2_PACKAGE_VIRGLRENDERER_DRM_BACKEND_AMDGPU \
>> etc..
>>
>> (sorry for the very long comment line)
>>
>
> I think additional messaging in the Config.in help line would benefit
> users. Maybe even a defconfig or test case demonstrating setup?
Having a test case running in gitlab-ci environment demonstrating this setup is
definitively welcome (If running in gitlab-ci environment is possible).
Buildroot defconfigs are used as initial/minimal configuration to boot a board,
they should not contain any additional packages.
Thanks for your detailled explanations!
Best regards,
Romain
>
> [0] https://gitlab.freedesktop.org/virgl/virglrenderer/-/merge_requests/1568
>
> Best,
> Joseph
More information about the buildroot
mailing list