linux-kernel - Re: [PATCH v3 0/2] efi/x86: Call set

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:
 <MA0P287MB021789D73CAD62C16BCF0306B8AA2@MA0P287MB0217.INDP287.PROD.OUTLOOK.COM>
Date: Wed, 24 Jul 2024 16:26:58 +0000
From: Aditya Garg <gargaditya08@...e.com>
To: Lukas Wunner <lukas@...ner.de>
CC: Ard Biesheuvel <ardb@...nel.org>, "linux-efi@...r.kernel.org"
	<linux-efi@...r.kernel.org>, "linux-kernel@...r.kernel.org"
	<linux-kernel@...r.kernel.org>, Hans de Goede <hdegoede@...hat.com>, Kerem
 Karabay <kekrby@...il.com>, Orlando Chamberlain <orlandoch.dev@...il.com>,
	"sharpenedblade@...ton.me" <sharpenedblade@...ton.me>
Subject: Re: [PATCH v3 0/2] efi/x86: Call set_os() protocol on dual GPU Macs



> On 24 Jul 2024, at 9:31 PM, Lukas Wunner <lukas@...ner.de> wrote:
> 
> On Tue, Jul 23, 2024 at 04:25:19PM +0000, Aditya Garg wrote:
>>> On Wed, Jul 17, 2024 at 04:35:15PM +0000, Aditya Garg wrote:
>>> For the Macs having a single GPU, in case a person uses an eGPU,
>>> they still need this apple-set-os quirk for hybrid graphics.
>> 
>> Sending this message again as for some reason it got sent only to Lukas:
>> 
>> Full model name: Mac mini (2018) (Macmini8,1)
>> 
>> The drive link below has the logs:
>> 
>> https://drive.google.com/file/d/1P3-GlksU6WppvzvWC0A-nAoTZh7oPPxk/view?usp=drive_link
> 
> Some observations:
> 
> * dmesg-with-egpu.txt:  It seems the system was actually booted *without*
>  an eGPU, so the filename appears to be a misnomer.
> 
> * The two files in the with_apple_set_os_efi directory only contain
>  incomplete dmesg output.  Boot with log_buf_len=16M to solve this.
>  Fortunately the truncated log is sufficient to see what's going on.
> 
> * If the apple_set_os protocol is not used, the attached eGPU is not
>  enumerated by the kernel on boot and a rescan is required.
>  So neither the iGPU nor the eGPU are working.  The reason is BIOS
>  sets up incorrect bridge windows for the Thunderbolt host controller:
>  Its two downstream ports' 64-bit windows overlap.  The 32-bit windows
>  do not overlap.  If apple_set_os is used, the eGPU is using the
>  (non-overlapping) 32-bit window.  If apple_set_os is not used,
>  the attached eGPU is using the (overlapping, hence broken) 64-bit window.  
> 
>  So not only is apple_set_os needed to keep the iGPU enabled,
>  but also to ensure BIOS sets up bridge windows in a manner that is
>  only halfway broken and not totally broken.
> 
>  Below, 0000:06:01.0 and 0000:06:04.0 are the downstream ports on the
>  Thunderbolt host controller and 0000:09:00.0 is the upstream port of
>  the attached eGPU.
> 
>  iGPU enabled, no eGPU attached (dmesg.txt):
>  pci 0000:06:01.0:   bridge window [mem 0x81900000-0x888fffff]
>  pci 0000:06:01.0:   bridge window [mem 0xb1400000-0xb83fffff 64bit pref]
>  pci 0000:06:04.0:   bridge window [mem 0x88900000-0x8f8fffff]
>  pci 0000:06:04.0:   bridge window [mem 0xb8400000-0xbf3fffff 64bit pref]
> 
>  iGPU disabled, eGPU attached, apple_set_os not used (journalctl.txt):
>  pci 0000:06:01.0:   bridge window [mem 0x81900000-0x888fffff]
>  pci 0000:06:01.0:   bridge window [mem 0xb1400000-0xc6ffffff 64bit pref]
>  pci 0000:06:04.0:   bridge window [mem 0x88900000-0x8f8fffff]
>  pci 0000:06:04.0:   bridge window [mem 0xb8400000-0xbf3fffff 64bit pref]
>  pci 0000:06:04.0: bridge window [mem 0xb8400000-0xbf3fffff 64bit pref]: can't claim; address conflict with PCI Bus 0000:09 [mem 0xb1400000-0xbf3fffff 64bit pref]
> 
>  iGPU enabled, eGPU attached, apple_set_os used (working-journalctl.txt):
>  pci 0000:06:01.0:   bridge window [mem 0x81900000-0x888fffff]
>  pci 0000:06:01.0:   bridge window [mem 0xb1400000-0xc6ffffff 64bit pref]
>  pci 0000:06:04.0:   bridge window [mem 0x88900000-0x8f8fffff]
>  pci 0000:06:04.0:   bridge window [mem 0xb8400000-0xbf3fffff 64bit pref]
>  pci 0000:09:00.0:   bridge window [mem 0x81900000-0x81cfffff]
> 
> * As to how we can solve this and keep using apple_set_os only when
>  necessary:
> 
>  I note that on x86, the efistub walks over all PCI devices in the system
>  (see setup_efi_pci() in drivers/firmware/efi/libstub/x86-stub.c) and
>  retrieves the Device ID and Vendor ID.  We could additionally retrieve
>  the Class Code and count the number of GPUs in the system by checking
>  whether the Class Code matches PCI_BASE_CLASS_DISPLAY.  If there's
>  at least 2 GPUs in the system, invoke apple_set_os.

This also looks like a good idea, but I'm not well aware of the pci quirks in the Linux kernel. So, would consider it a bug report for the maintainers to fix.
> 
>  The question is whether this is needed on *all* Apple products or only
>  on newer ones.  I suspect that the eGPU issue may be specific to
>  recent products.  Ideally we'd find someone with a Haswell or Ivy Bridge
>  era Mac Mini and an eGPU who could verify whether apple_set_os is needed
>  on older models as well.
> 
>  We could constrain apple_set_os to newer models by checking for
>  presence of the T2 PCI device [106b:1802].  Alternatively, we could
>  use the BIOS date (DMI_BIOS_DATE in SMBIOS data) to enforce a
>  cut-off such that only machines with a recent BIOS use apple_set_os.
> 
> Thanks,
> 
> Lukas