On 2023-03-20 13:12, Javier Martinez Canillas wrote:

Samuel Čavoj [off-list ref] writes:

[...]

quoted

quoted

quoted

quoted

This call to sysfb_disable() has been causing trouble with regard 
to
VFIO. VFIO has been calling aperture_remove_conflicting_pci_devices
to
get rid of any console drivers (d173780620792c) using the device in
question, but now even unrelated drivers are getting killed. 
Example
situation:

Which drivers do you use?

This happens with either no drivers loaded or the proprietary nvidia
driver. Nouveau is fine as it doesn't rely on efifb but brings its 
own.

Which is what all DRM drivers should do. If they want to make sure that 
a
fbdev will be present after the DRM driver probes, then should register 
an
emulated fbdev.

I don't see how this is specific to Nvidia or DRM drivers.

The efifb is killed if vfio-pci (or another driver which uses the
aperture system to remove conflicting drivers) is bound to ANY pci
device, regardless of whether it's nvidia's fault for not implementing
a framebuffer. Fair enough, I agree that they should, but
I for one expect my efifb to not die at a random time
when a random unrelated driver does a random thing with another
unrelated GPU.

Or is the efifb considered a stop-gap solution the only purpose of
which is early boot--before another GPU driver is loaded?

There was an attempt to workaround that in [0], in particular patch [1]
but that effort was not continued since the only DRM driver that would 
be
affected is the Nvidia proprietary driver that relies on 
efifb/simpledrm
to have a VT.

[0]: 
https://patchwork.kernel.org/project/dri-devel/list/?series=711019&archive=both
[1]: 
https://patchwork.kernel.org/project/dri-devel/patch/20230111154112.90575-11-daniel.vetter@ffwll.ch/