On Thu, Dec 19, 2024 at 12:23:37PM +0100, Borislav Petkov wrote: > + Yazen. > > On Mon, Dec 16, 2024 at 02:15:26PM +0100, Rostyslav Khudolii wrote: > > Hi all, > > > > I am currently working on a custom AMD Ryzen™ Embedded R2000 (AMD > > Family 17h) device and have discovered that PCI IO Extended > > Configuration Space (ECS) access is no longer possible. > > Perhaps that particular type of system of yours needs some special handling. > > Things to try: > > * use the latest upstream kernel > > * add some debug printks to the paths you mention to see where they fail > > Looking at the relevant chapter in the PPR - 2.1.7 or 2.1.8 - that > should still work. > > Leaving in the rest for reference. > > > Consider the following functions: amd_bus_cpu_online() and > > pci_enable_pci_io_ecs(). These functions are part of the > > amd_postcore_init() initcall and are responsible for enabling PCI IO > > ECS. Both functions modify the CoreMasterAccessCtrl (EnableCf8ExtCfg) > > value via the PCI device function or the MSR register directly (see > > the "BIOS and Kernel Developer’s Guide (BKDG) for AMD Family 15h", > > Section 2.7). However, neither the MSR register nor the PCI function > > at the specified address (D18F3x8C) exists for AMD Family 17h. The > > CoreMasterAccessCtrl register still exists but is now located at a > > different address (see the "Processor Programming Reference (PPR) for > > AMD Family 17h", Section 2.1.8). > > > > I would be happy to submit a patch to fix this issue. However, since > > the most recent change affecting this functionality appears to be 14 > > years old, I would like to confirm whether this is still relevant or > > if the kernel should always be built with CONFIG_PCI_MMCONFIG when ECS > > access is required. > > Hi Ros, I expect you would want CONFIG_ACPI_MCFG and the "MCFG" table should be provided through ACPI. Can you please confirm if this config option is enabled, and that the system provides MCFG? > > Linux Kernel info: > > > > root@qt5222:~# uname -a > > Linux qt5222 6.6.49-2447-qtec-standard--gef032148967a #1 SMP Fri Nov > > 22 09:25:55 UTC 2024 x86_64 GNU/Linux > > The ECS space is expected to be enabled by BIOS and advertised through ACPI. The oldest public doc I found mentions this. This is the BKDG for Family 10h dated from 2013, and the product was launched in 2007. https://www.amd.com/content/dam/amd/en/documents/archived-tech-docs/programmer-references/31116.pdf "The BIOS may use either configuration space access mechanism during boot. Before booting the OS, BIOS must disable IO access to ECS, enable MMIO configuration and build an ACPI defined MCFG table. BIOS ACPI code must use MMIO to access configuration space. " This paragraph remains unchanged through the docs for the latest products. The PCI Firmware space v3.0, dated from 2005, has this in an implementation note: "If this platform also needs to support legacy operating systems or x86 BIOS Option ROMs, the CF8/CFCh access mechanism (which is PCI Segment Group unaware and only can support up to 256 bus numbers) must also be supported." My understanding, based on the above info, is that ACPI should be used. The direct register enablement is still possible for backwards compatibility, if needed. I think your observation proves a good point. The registers were moved starting in Zen. But this is not an issue on modern OSes since ACPI is used by default. For your specific issue, I think we should determine if there is a configuration or a firmware problem. There's also a difference between "early" and "late" mmcfg init. But I think we need to have more details on the issue. Thanks, Yazen P.S. Thanks for reporting this! It's a good question, and I find doing "archaeological" research enjoyable. :) P.P.S. For the maintainers: should we consider cleaning up legacy code such as this?
