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

Thomas Zimmermann [off-list ref] writes:

[...]

quoted

quoted

quoted

+    /*
+     * If a driver asked to unregister a platform device registered 
by
+     * sysfb, then can be assumed that this is a driver for a 
display
+     * that is set up by the system firmware and has a generic 
driver.
+     *
+     * Drivers for devices that don't have a generic driver will 
never
+     * ask for this, so let's assume that a real driver for the 
display
+     * was already probed and prevent sysfb to register devices 
later.
+     */
+    sysfb_disable();

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.

quoted

Also, what kernel version?

I tried with 6.2.6, can build mainline and test there as well.

Thanks for help!

[...]

quoted

quoted

Machine has two GPUs and uses efifb for the console. Efifb registers
with the aperture system the efi framebuffer region, which is covered
by a BAR resource of GPU 1. VFIO grabs GPU 2 and calls
aperture_remove_conflicting_pci_devices(GPU 2). GPU 2 has no overlap
with the efifb on GPU1 but the efifb is killed regardless due to
the unconditional call to sysfb_disable(). The console switches
to dummy and locks up from the user perspective.
This seems unnecessary, as the device is unrelated.

That's a bug indeed but I thought that was already fixed...