From: Ingo Molnar <mingo@kernel.org>
To: Rostyslav Khudolii <ros@qtec.com>
Cc: Yazen Ghannam <yazen.ghannam@amd.com>,
Borislav Petkov <bp@alien8.de>,
linux-pci@vger.kernel.org, linux-kernel@vger.kernel.org,
x86@kernel.org, "bhelgaas@google.com" <bhelgaas@google.com>,
"tglx@linutronix.de" <tglx@linutronix.de>
Subject: Re: PCI IO ECS access is no longer possible for AMD family 17h
Date: Mon, 3 Mar 2025 12:32:08 +0100 [thread overview]
Message-ID: <Z8WTON2K77Q567Kg@gmail.com> (raw)
In-Reply-To: <CAJDH93uE+foFfRAXVJ48-PYvEUsbpEu_-BVoG-5HsDG66yY7AQ@mail.gmail.com>
* Rostyslav Khudolii <ros@qtec.com> wrote:
> Hi,
>
> > Rostyslav, I would like to ask you, do you have patches / updates for
> > enabling the EnableCf8ExtCfg bit for AMD 17h+ family? I could try to
> > adjust my lspci changes for new machines.
>
> Pali, sorry for the late reply. Do I understand correctly, that even
> though you have access to the ECS via
> the MMCFG you still want the legacy (direct IO) to work for the
> debugging purposes? I can prepare a
> simple patch that will allow you to do so if that's the case.
>
> >
> > So what is the practical impact here? Do things start breaking
> > unexpectedly if CONFIG_ACPI_MCFG and CONFIG_PCI_MMCONFIG are disabled?
> > Then I'd suggest fixing that in the Kconfig space, either by adding a
> > dependency on ACPI_MCFG && PCI_MMCONFIG, or by selecting those
> > must-have pieces of infrastructure.
> >
>
> Ingo, thank you for the reply.
>
> The way I understand the access to the PCI ECS (via raw_pci_ext_ops)
> works, is the following:
> 1. If CONFIG_ACPI_MCFG or CONFIG_PCI_MMCONFIG are enabled - set the
> raw_pci_ext_ops to use
> MMCFG to access ECS. See pci_mmcfg_early_init() / pci_mmcfg_late_init();
> 2. If CONFIG_ACPI_MCFG and CONFIG_PCI_MMCONFIG are disabled - set the
> raw_pci_ext_ops to use
> the 'direct' access to ECS. See pci_direct_init(). The direct
> access is conditional on the PCI_HAS_IO_ECS
> flag being set.
>
> On AMD, the kernel enables the ECS IO access via the
> amd_bus_cpu_online() and pci_enable_pci_io_ecs().
> Except those functions have no desired effect on the AMD 17h+ family
> because the register (EnableCf8ExtCfg),
> they access, has been moved. What is important though, is that the
> PCI_HAS_IO_ECS flag is set unconditionally.
> See pci_io_ecs_init() in amd_bus.c
>
> Therefore I was wondering whether we should add support for the 17h+
> family in those functions to have
> the direct access work for those families as well.
Yeah, I think so, but I'm really just guessing:
> Regarding your suggestion to address this in the Kconfig space - I'm
> not quite sure I follow, since right now the kernel will use
> raw_pci_ext_ops whenever access beyond the first 256 bytes is
> requested. Say we want to make that conditional on CONFIG_ACPI_MCFG
> and CONFIG_PCI_MMCONFIG, does it also mean then we want to drop
> support for the 'direct' PCI IO ECS access altogether?
I thought that enabling CONFIG_ACPI_MCFG would solve the problem, and
other architectures are selecting it pretty broadly:
arch/arm64/Kconfig: select ACPI_MCFG if (ACPI && PCI)
arch/loongarch/Kconfig: select ACPI_MCFG if ACPI
arch/riscv/Kconfig: select ACPI_MCFG if (ACPI && PCI)
While x86 allows it to be user-configured, which may result in
misconfiguration, given that PCI_HAS_IO_ECS is being followed
unconditionally if a platform provides it?
Thanks,
Ingo
next prev parent reply other threads:[~2025-03-03 11:32 UTC|newest]
Thread overview: 20+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-12-16 13:15 PCI IO ECS access is no longer possible for AMD family 17h Rostyslav Khudolii
2024-12-19 11:23 ` Borislav Petkov
2024-12-19 16:44 ` Yazen Ghannam
2024-12-27 11:07 ` Rostyslav Khudolii
2025-02-26 15:07 ` Ingo Molnar
2025-03-03 9:21 ` Rostyslav Khudolii
2025-03-03 11:32 ` Ingo Molnar [this message]
2025-03-03 12:20 ` Rostyslav Khudolii
2025-03-03 18:42 ` Yazen Ghannam
2025-03-04 7:39 ` Rostyslav Khudolii
2025-03-04 15:26 ` Yazen Ghannam
2025-06-21 14:50 ` Pali Rohár
2025-07-15 10:43 ` Rostyslav Khudolii
2025-07-15 17:06 ` Pali Rohár
2025-07-16 8:03 ` Rostyslav Khudolii
2025-07-16 18:13 ` Pali Rohár
2025-08-11 17:57 ` Pali Rohár
2025-08-26 15:07 ` Rostyslav Khudolii
2025-08-26 18:09 ` Pali Rohár
2025-01-22 22:13 ` Pali Rohár
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=Z8WTON2K77Q567Kg@gmail.com \
--to=mingo@kernel.org \
--cc=bhelgaas@google.com \
--cc=bp@alien8.de \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-pci@vger.kernel.org \
--cc=ros@qtec.com \
--cc=tglx@linutronix.de \
--cc=x86@kernel.org \
--cc=yazen.ghannam@amd.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.