Re: [PATCH] x86/iommu: setup MMCFG ahead of IOMMU

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

On Wed, Aug 20, 2025 at 12:37:51PM +0100, Andrew Cooper wrote:
> On 20/08/2025 12:33 pm, Roger Pau Monné wrote:
> > On Tue, Aug 19, 2025 at 07:23:57PM +0100, Andrew Cooper wrote:
> >> On 19/08/2025 6:18 pm, Roger Pau Monne wrote:
> >>> diff --git a/xen/arch/x86/setup.c b/xen/arch/x86/setup.c
> >>> index 6fb42c5a5f95..bd648323bfed 100644
> >>> --- a/xen/arch/x86/setup.c
> >>> +++ b/xen/arch/x86/setup.c
> >>> @@ -1938,11 +1938,10 @@ void asmlinkage __init noreturn __start_xen(void)
> >>>      setup_system_domains();
> >>>  
> >>>      /*
> >>> -     * Ahead of any ACPI table parsing make sure we have control structures
> >>> -     * for PCI segment 0.
> >>> +     * Initialize PCI (create segment 0, setup MMCFG access) ahead of IOMMU
> >>> +     * setup, as it requires access to the PCI config space.
> >>>       */
> >> Again, this isn't terribly clear IMO.
> >>
> >> "ahead of IOMMU setup, as the IOMMUs might not all live on segment 0." ?
> > It's not just IOMMUs, but for example on VT-d we also need to poke at
> > the config space of bridges, and when such bridges live in segment > 0
> > that results in garbage being returned.
> >
> > I'm not sure acpi_iommu_init() accesses the IOMMU PCI device config
> > space, but it does at least access the config space of bridges in
> > order to detect hierarchy.  See how acpi_parse_dev_scope() performs
> > PCI reads.
> >
> > What about using:
> >
> > /*
> >  * Initialize PCI (create segment 0, setup MMCFG access) ahead of IOMMU
> >  * setup, as devices in segment > 0 must also be discoverable.
> >  */
> 
> Yeah, that works.
> 
> With those comment adjustments, Reviewed-by: Andrew Cooper
> <andrew.cooper3@citrix.com>

Forgot to add it, this patch should have:

Fixes: 3950f2485bbc ('x86/x2APIC: defer probe until after IOMMU ACPI table parsing')

In the commit message.

Thanks, Roger.