# Re: \[PATCH v2 07/11\] video/aperture: Disable and unregister sysfb devices via aperture helpers

- From: Samuel Čavoj \<hidden\>
- Date: 2023-03-20 11:08:19 
- List: linux-fbdev
- Page: https://ratatoskr.run/linux-fbdev/2023/03/9232584
- Thread: https://ratatoskr.run/linux-fbdev/2022/07/9222229/t.md

```text
On 2023-03-20 11:13, Javier Martinez Canillas wrote:
> Thomas Zimmermann [ref] 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...
```