On Mon, Feb 27, 2023 at 07:40:11AM -0800, Rob Clark wrote: > On Sun, Feb 26, 2023 at 10:38 PM Gerd Hoffmann <kraxel@xxxxxxxxxx> wrote: > > > > On Fri, Feb 24, 2023 at 10:02:24AM -0800, Rob Clark wrote: > > > From: Rob Clark <robdclark@xxxxxxxxxxxx> > > > > > > Add a build option to disable modesetting support. This is useful in > > > cases where the guest only needs to use the GPU in a headless mode, or > > > (such as in the CrOS usage) window surfaces are proxied to a host > > > compositor. > > > > Why make that a compile time option? There is a config option for the > > number of scanouts (aka virtual displays) a device has. Just set that > > to zero (and fix the driver to not consider that configuration an > > error). > > The goal is to not advertise DRIVER_MODESET (and DRIVER_ATOMIC).. I > guess that could be done based on whether there are any scanouts, but > it would mean making the drm_driver struct non-const. Apparently there is a drm_device->driver_features override, (amdgpu uses that). The driver could simply drop the DRIVER_MODESET and DRIVER_ATOMIC bits in case no scanout is present instead of throwing an error. > And I think it is legitimate to allow the guest to make this choice, > regardless of what the host decides to expose, since it is about the > ioctl surface area that the guest kernel exposes to guest userspace. I think it is a bad idea to make that a compile time option, I'd suggest a runtime switch instead, for example a module parameter to ask the driver to ignore any scanouts. take care, Gerd _______________________________________________ Virtualization mailing list Virtualization@xxxxxxxxxxxxxxxxxxxxxxxxxx https://lists.linuxfoundation.org/mailman/listinfo/virtualization