On 2023-03-20 11:13, Javier Martinez Canillas wrote:
Thomas Zimmermann <tzimmermann@xxxxxxx> writes:
[...]
+ /*
+ * 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.
Also, what kernel version?
I tried with 6.2.6, can build mainline and test there as well.
Thanks for help!
[...]
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...
