On systems where the ACPI DSDT advertises the PCI MMCONFIG area but the
E820 table does not reserve it, it's up to Dom0 to inform Xen via
PHYSDEVOP_pci_mmcfg_reserved. This needs to happen before Xen tries to
access extended capabilities like SRIOV in pci_add_device(), which is
triggered when Linux enumerates PCI devices in acpi_init(). Changing
xen_mcfg_late() to arch_initcall_sync ensures it gets called before
acpi_init(), but after pci_mmcfg_list is populated by pci_arch_init().
Without this change, Xen 4.4 and 4.5 emit WARN messsages from
msix_capability_init() when setting up Intel 82599 VFs, since vf_rlen has
not been initialized by pci_add_device(). And on Xen 4.5, Xen nukes the
DomU due to "Potentially insecure use of MSI-X" when the VF driver loads
in the DomU. Both problems are fixed by this change.
Signed-off-by: Ed Swierk <eswi...@skyportsystems.com>
---
drivers/xen/pci.c | 6 ++++--
1 file changed, 4 insertions(+), 2 deletions(-)
diff --git a/drivers/xen/pci.c b/drivers/xen/pci.c
index 7494dbe..7b5bbdb 100644
--- a/drivers/xen/pci.c
+++ b/drivers/xen/pci.c
@@ -253,7 +253,9 @@ static int __init xen_mcfg_late(void)
return 0;
}
/*
- * Needs to be done after acpi_init which are subsys_initcall.
+ * Needs to be called after pci_arch_init (arch_initcall) populates
+ * pci_mmcfg_list, but before acpi_init (subsys_initcall) triggers
+ * pci_add_device() in Xen, since the latter probes extended capabilities.
*/
-subsys_initcall_sync(xen_mcfg_late);
+arch_initcall_sync(xen_mcfg_late);
#endif
--
1.9.1
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
