linux-kernel - Re: [Nouveau] [RFC, drm-misc-next v4 0/9] PCI/VGA: Allowing the user to select the primary video adapter at boot time

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <0ace21b2-f0ce-0b14-529f-c0ee2adf972f@suse.de>
Date:   Wed, 6 Sep 2023 09:18:17 +0200
From:   Thomas Zimmermann <tzimmermann@...e.de>
To:     suijingfeng <suijingfeng@...ngson.cn>,
        Sui Jingfeng <sui.jingfeng@...ux.dev>,
        Bjorn Helgaas <bhelgaas@...gle.com>,
        "Koenig, Christian" <Christian.Koenig@....com>,
        Jani Nikula <jani.nikula@...ux.intel.com>,
        Daniel Vetter <daniel@...ll.ch>,
        "Deucher, Alexander" <Alexander.Deucher@....com>
Cc:     nouveau@...ts.freedesktop.org, intel-gfx@...ts.freedesktop.org,
        linux-kernel@...r.kernel.org, amd-gfx@...ts.freedesktop.org,
        dri-devel@...ts.freedesktop.org, linux-pci@...r.kernel.org
Subject: Re: [Nouveau] [RFC, drm-misc-next v4 0/9] PCI/VGA: Allowing the user
 to select the primary video adapter at boot time

Hi

Am 06.09.23 um 04:34 schrieb suijingfeng:
> 
> On 2023/9/5 23:05, Thomas Zimmermann wrote:
>> Hi
>>
>> Am 05.09.23 um 15:30 schrieb suijingfeng:
>>> Hi,
>>>
>>>
>>> On 2023/9/5 18:45, Thomas Zimmermann wrote:
>>>> Hi
>>>>
>>>> Am 04.09.23 um 21:57 schrieb Sui Jingfeng:
>>>>> From: Sui Jingfeng <suijingfeng@...ngson.cn>
>>>>>
>>>>> On a machine with multiple GPUs, a Linux user has no control over 
>>>>> which
>>>>> one is primary at boot time. This series tries to solve above 
>>>>> mentioned
>>>>
>>>> If anything, the primary graphics adapter is the one initialized by 
>>>> the firmware. I think our boot-up graphics also make this assumption 
>>>> implicitly.
>>>>
>>>
>>> Yes, but by the time of DRM drivers get loaded successfully,the 
>>> boot-up graphics already finished.
>>> Firmware framebuffer device already get killed by the 
>>> drm_aperture_remove_conflicting_pci_framebuffers()
>>> function (or its siblings). So, this series is definitely not to 
>>> interact with the firmware framebuffer
>>
>> Yes and no. The helpers you mention will attempt to remove the 
>> firmware framebuffer on the given PCI device. If you have multiple PCI 
>> devices, the other devices would not be affected.
>>
> Yes and no.
> 
> 
> For the yes part: drm_aperture_remove_conflicting_pci_framebuffers() 
> only kill the conflict one.
> But for a specific machine with the modern UEFI firmware,
> there should be only one firmware framebuffer driver.
> That shoudd be the EFIFB(UEFI GOP). I do have multiple PCI devices,
> but I don't understand when and why a system will have more than one 
> firmware framebuffer.

Maybe somewhat unrelated to the actual discussion, but it's not as 
simple as you assume. Many non-X86 systems use DeviceTree. On Sparc 
IIRC, there's the case of having multiple firmware framebuffers listed 
in the DT. We create an device for each and attach a DRM firmware 
driver; ofdrm in this case. I haven't seen this in the wild, but 
non-Sparc systems could also behave like that.

And in addition to that, ARM-based systems often uses UEFI boot stub 
code that provides a simple UEFI environment to the kernel. For graphics 
we've had cases where we received the same firmware framebuffer from the 
DT and from the UEFI boot stub. We have to detect and handle such 
duplication in the kernel.

Best regards
Thomas

> 
> Even for the machines with the legacy BIOS, the fixed VGA aperture 
> address range
> can only be owned by one firmware driver. It is just that we need to 
> handle the
> routing, the ->set_decode() callback of vga_client_register() is used to 
> do such
> work. Am I correct?
> 
> 

-- 
Thomas Zimmermann
Graphics Driver Developer
SUSE Software Solutions Germany GmbH
Frankenstrasse 146, 90461 Nuernberg, Germany
GF: Ivo Totev, Andrew Myers, Andrew McDonald, Boudien Moerman
HRB 36809 (AG Nuernberg)

Download attachment "OpenPGP_signature" of type "application/pgp-signature" (841 bytes)