Thomas Zimmermann <tzimmermann@xxxxxxx> writes: > Hi > > Am 28.02.23 um 10:19 schrieb Javier Martinez Canillas: >> Gerd Hoffmann <kraxel@xxxxxxxxxx> writes: > [...] >>> >>> 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. >>> >> >> I don't think there's a need for a new module parameter, there's already >> the virtio-gpu 'modeset' module parameter to enable/disable modsetting >> and the global 'nomodeset' kernel cmdline parameter to do it for all DRM >> drivers. >> >> Currently, many drivers just fail to probe when 'nomodeset' is present, >> but others only disable modsetting but keep the rendering part. In fact, >> most DRM only drivers just ignore the 'nomodeset' parameter. > > Do you have a list of these drivers? Maybe we need to adjust semantics > slightly. Please see my comment below. > AFAIK i915 and nouveau do this. But also on the rpi4 only the vc4 display driver is disabled but the v3d driver used for rendering is not disabled. So the 'nomodeset' semantics are not consistent across all DRM drivers. [...] >> - if (virtio_gpu_modeset == 0) >> - return -EINVAL; >> + if ((drm_firmware_drivers_only() && virtio_gpu_modeset == -1) || >> + (virtio_gpu_modeset == 0)) >> + driver.driver_features &= ~(DRIVER_MODESET | DRIVER_ATOMIC); > > The kernel-wide option 'nomodeset' affects system behavior. It's a > misnomer, as it actually means 'don't replace the firmware-provided > framebuffer.' So if you just set these flags here, virtio-gpu would > later remove the firmware driver via aperture helpers. Therefore, if > drm_formware_drivers_only() returns true, we should fail probing with > -ENODEV. > Right. Or the DRM aperture helper shouldn't attempt to remove the firmware provided framebuffer if the DRM driver doesn't have the DRIVER_MODESET set. > But we could try to repurpose the module's 'modeset' option. It's > already obsoleted by nomodeset anyway. I'd try to make modeset it a > boolean that controls modesetting vs render-only. It will then be about > the driver's feature set, rather than system behavior. > Yes, that could work too. Dmitry mentioned that Rob wanted the compile-time option to reduce the attack surface area. I don't have a strong opinion on this, but just wanted to point out that there wasn't a need for a new param and that the existing module's 'modeset' could be repurposed for this case. -- Best regards, Javier Martinez Canillas Core Platforms Red Hat
