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

[Andrew Cooper <andrew.cooper3@xxxxxxxxxx>]

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.

There's also loads of code improvements to be had.  The current APIs are
inefficient to use, and I did some cleanup for them for Trenchboot where
there is a 64k limit.  (But this can strictly come later).

~Andrew