>>> On 16.08.18 at 07:10, <zhenzhong.d...@oracle.com> wrote: > On a multiple pci segment system such as HPE Superdome-Flex, pci config space > from nonzero segment is accessed with mmcfg during acpi parsing DMAR region.
First of all - can you please write a little more helpful (to reviewers) patch description. I had to hunt down the config space accesses instead of you clearly saying where they are (and why they are unavoidably there). Furthermore you also move the invocation of pt_pci_init(), with no explanation at all. I did not want to invest the time to understand why that's needed. > We need to setup mmcfg mapping before that or else drhd isn't correctly setup > and devices under it fail to load in dom0. That's the improvement side of the change. Mind also saying a word on why the reordering won't break any other dependencies? After all you move up the functions across dozens of other ones, not the least far ahead of the point where IRQs get enabled the first time. Have you investigated the alternative of deferring acpi_dmar_init() to a later point, or at least the part of it that needs to do PCI config space accesses? I'm not currently convinced the device scope parsing needs to happen that early: Neither iommu_supports_eim() nor iommu_enable_x2apic_IR() look to depend on that information at the first glance, and I think these are the routines that require (part of) the DMAR parsing to happen early. > --- a/xen/arch/x86/setup.c > +++ b/xen/arch/x86/setup.c > @@ -1493,6 +1493,10 @@ void __init noreturn __start_xen(unsigned long mbi_p) > > generic_apic_probe(); > > + pt_pci_init(); > + > + acpi_mmcfg_init(); > + > acpi_boot_init(); With the dependency being _in_ acpi_boot_init(), the invocation of acpi_mmcfg_init() should now be moved there. Jan _______________________________________________ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
