Re: [PATCH v1 0/2] x86/pci: MMCFG improvements and always use it if available

["Roger Pau Monné" <roger.pau@citrix.com>]

On Wed, Jan 07, 2026 at 06:07:56PM +0000, Andrew Cooper wrote:
> On 07/01/2026 5:58 pm, Teddy Astie wrote:
> > Le 07/01/2026 à 18:25, Roger Pau Monné a écrit :
> >> On Wed, Jan 07, 2026 at 04:54:55PM +0000, Teddy Astie wrote:
> >>> Currently, Xen uses legacy method to access the configuration space unless the
> >>> access cannot be made with it, where Xen fallbacks to MMCFG. This is not really
> >>> great, as MMCFG is more flexible and doesn't require a dedicated lock, so it would
> >>> be preferable to use it whenever possible.
> >>>
> >>> Teddy Astie (2):
> >>>    x86/pci: Improve pci_mmcfg_{read,write} error handling
> >>>    x86/pci: Prefer using mmcfg for accessing configuration space
> >> AFAICT Linux is using the same approach as Xen to perform PCI
> >> accesses.
> 
> I think you mean "Xen inherited it's PCI code from Linux". :)
> 
> >>   Registers below 256 on segment 0 are accessed using the
> >> legacy method (IO ports), while the extended space is accessed using
> >> MMCFG.  Do you know the reason for this?  I fear there might be
> >> legacy devices/bridges (or root complexes?) where MMCFG is not
> >> working as expected?
> >>
> > There is apparently a errata on some K8 chipset according to FreeBSD 
> > code that uses MMCFG whenever possible.
> >
> > https://github.com/freebsd/freebsd-src/blob/main/sys/amd64/pci/pci_cfgreg.c#L261-L277
> 
> Using MMCFG is *far* more efficient than IO ports, not least because we
> can avoid serialising accesses across the system.
> 
> If it really is only some K8's which were the problem then lets go the
> FreeBSD way.  Both Linux and Xen both talk about AMD Fam10h issues,
> which is the fact that early AMD CPUs only allow MMCFG accesses for
> MOV-EAX instructions.

Sorry if my previous reply made it look the opposite, I'm all fine
with switching to MMCFG by default, but we need the K8 workaround,
plus this needs to be noted in the commit message.

I wonder if we could use alternative calls to patch MMCFG only access
on capable systems, thus removing the check for the fallback legacy
access on such systems.

Thanks, Roger.