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.coop...@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.
