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? > Also, what kernel version? [...] >> >> 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... -- Best regards, Javier Martinez Canillas Core Platforms Red Hat
