Received: by 2002:a25:c593:0:0:0:0:0 with SMTP id v141csp2663177ybe; Thu, 12 Sep 2019 12:53:39 -0700 (PDT) X-Google-Smtp-Source: APXvYqy3hjGUvu1GtSAt4dhNbdCGb2sywA3/PN50hLwAogibnq1lFPcasETBjmxxrS2O2XWULg/+ X-Received: by 2002:aa7:d414:: with SMTP id z20mr18218987edq.208.1568318018963; Thu, 12 Sep 2019 12:53:38 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1568318018; cv=none; d=google.com; s=arc-20160816; b=a7e1uxE1JzFat0t5RaH+nSYGDoQkq5AXT9Ys7l18FIUbZQkadJHJ71Md3lEZEJ2kIO HB6yuzaNi62xI3EHDR7NGfdYEpSz91Y2dLYw+bl39rKp/JQRAhX7B544Akq9ONMVKRYA M9KkqAYjEAKpzOYPY87jRhejYj/Lm0c1YqrKN1kbbCfJs8tCGqtMsHd4g9tu/nPmKnSN pQxt3cViQ3Sxt0X2+hy4xMBFCi6gpCMRlT4gFQsKlyykMhOh+ozYtS7fojKJbEjfz9sw +GmsXmrmgXZrBBfwWb3EnqEeCiyXDqDXKTW7rObMtRsBEgjpO8TxeaYtuaUVl48ni9kc R+sg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:mime-version:message-id:date:subject:cc :to:from:ironport-sdr:dkim-signature; bh=M/G7DpPgNFtjl7mWfxEN6xa/uFIPVFRKs6tSYixGZ9M=; b=tTdebJkNLOer1P2SQlt7xHXE0ivsUeOfeD4d2l1avHXDpC3Ez3//xM+xDyXI6+bifP dqpxZojCJA8qG2YNBK1+71sqk+82Xf05rLT6+4bBOYDQcyVtglpqD+cWQmnI7kPrPJJa CWOksZJcf6Hn/DvXH+C3IYBYsRIYn25PWYr3Eoftht129GmPWMF6dnW2iNjb9BGhfbCh xy0vMOZj10d2UQYJMKHHqtQmmelcRiA1MtxTLsDL0by5OfWU7uBl4AP159Fc9P+YeCxC FZt6vlrheureS+bNDLWz5XPGPOyA3p6CqRqITuuwdanCurOY0REFp31fcxRJnh+VKRyK rs2g== ARC-Authentication-Results: i=1; mx.google.com; dkim=fail header.i=@citrix.com header.s=securemail header.b=FDTakulM; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id b34si15981893edb.439.2019.09.12.12.53.15; Thu, 12 Sep 2019 12:53:38 -0700 (PDT) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; dkim=fail header.i=@citrix.com header.s=securemail header.b=FDTakulM; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1727264AbfILSb5 (ORCPT + 99 others); Thu, 12 Sep 2019 14:31:57 -0400 Received: from esa2.hc3370-68.iphmx.com ([216.71.145.153]:58326 "EHLO esa2.hc3370-68.iphmx.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1725995AbfILSb4 (ORCPT ); Thu, 12 Sep 2019 14:31:56 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=citrix.com; s=securemail; t=1568313116; h=from:to:cc:subject:date:message-id:mime-version; bh=QsmWD8PSnspupJVf6MZ4cYzKMM/9pg8rauF0BOWjV+Q=; b=FDTakulMqzr90pbgYzhTrcqtPdaOb94uvHzfW6X5CNH95e1m98Lb2gNU nriUYjDSUQunxxNaAm/XEH3Wy7fJo6njWrs3nC4eAVkY5pWGWpsfwONB2 YFgaVL0y4aLNxc2Hsm7b59mrSH8lEEfNGvYZS57YnUSswpIFyTT+psRvX s=; Authentication-Results: esa2.hc3370-68.iphmx.com; dkim=none (message not signed) header.i=none; spf=None smtp.pra=igor.druzhinin@citrix.com; spf=Pass smtp.mailfrom=igor.druzhinin@citrix.com; spf=None smtp.helo=postmaster@mail.citrix.com Received-SPF: None (esa2.hc3370-68.iphmx.com: no sender authenticity information available from domain of igor.druzhinin@citrix.com) identity=pra; client-ip=162.221.158.21; receiver=esa2.hc3370-68.iphmx.com; envelope-from="igor.druzhinin@citrix.com"; x-sender="igor.druzhinin@citrix.com"; x-conformance=sidf_compatible Received-SPF: Pass (esa2.hc3370-68.iphmx.com: domain of igor.druzhinin@citrix.com designates 162.221.158.21 as permitted sender) identity=mailfrom; client-ip=162.221.158.21; receiver=esa2.hc3370-68.iphmx.com; envelope-from="igor.druzhinin@citrix.com"; x-sender="igor.druzhinin@citrix.com"; x-conformance=sidf_compatible; x-record-type="v=spf1"; x-record-text="v=spf1 ip4:209.167.231.154 ip4:178.63.86.133 ip4:195.66.111.40/30 ip4:85.115.9.32/28 ip4:199.102.83.4 ip4:192.28.146.160 ip4:192.28.146.107 ip4:216.52.6.88 ip4:216.52.6.188 ip4:162.221.158.21 ip4:162.221.156.83 ~all" Received-SPF: None (esa2.hc3370-68.iphmx.com: no sender authenticity information available from domain of postmaster@mail.citrix.com) identity=helo; client-ip=162.221.158.21; receiver=esa2.hc3370-68.iphmx.com; envelope-from="igor.druzhinin@citrix.com"; x-sender="postmaster@mail.citrix.com"; x-conformance=sidf_compatible IronPort-SDR: vyFn2YGzrF12PmyQmb3fO0TiOJTIiZV85vHIiOfuWOEobyx2em/gJnpGBZ212ZJWa+ilwnk5sA gE1+NP0NfSlzda9Y82we2igs+/m6zaYqGEKGsHb1SeH8ZyP5Pu9lWhuQjKePkc4OaQ1qivua9D 6HB2KGlM63h4LeBOkI7Ymb4z130ACkvZTcgvWUKMZp1M1Cjee7wnZ3LjYy0u7cPV8onpbSjnCK SrCm7T/c+GXfeisyoG2CofO5wPNA5qtgxKX/2vAd24sSGZiPIHJ7ahZiZtc1fKxean4+Zj9kCp LPg= X-SBRS: 2.7 X-MesageID: 5500270 X-Ironport-Server: esa2.hc3370-68.iphmx.com X-Remote-IP: 162.221.158.21 X-Policy: $RELAYED X-IronPort-AV: E=Sophos;i="5.64,498,1559534400"; d="scan'208";a="5500270" From: Igor Druzhinin To: , CC: , , Igor Druzhinin Subject: [PATCH v2] xen/pci: reserve MCFG areas earlier Date: Thu, 12 Sep 2019 19:31:51 +0100 Message-ID: <1568313111-14726-1-git-send-email-igor.druzhinin@citrix.com> X-Mailer: git-send-email 2.7.4 MIME-Version: 1.0 Content-Type: text/plain Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org If MCFG area is not reserved in E820, Xen by default will defer its usage until Dom0 registers it explicitly after ACPI parser recognizes it as a reserved resource in DSDT. Having it reserved in E820 is not mandatory according to "PCI Firmware Specification, rev 3.2" (par. 4.1.2) and firmware is free to keep a hole in E820 in that place. Xen doesn't know what exactly is inside this hole since it lacks full ACPI view of the platform therefore it's potentially harmful to access MCFG region without additional checks as some machines are known to provide inconsistent information on the size of the region. Now xen_mcfg_late() runs after acpi_init() which is too late as some basic PCI enumeration starts exactly there as well. Trying to register a device prior to MCFG reservation causes multiple problems with PCIe extended capability initializations in Xen (e.g. SR-IOV VF BAR sizing). There are no convenient hooks for us to subscribe to so register MCFG areas earlier upon the first invocation of xen_add_device(). It should be safe to do once since all the boot time buses must have their MCFG areas in MCFG table already and we don't support PCI bus hot-plug. Signed-off-by: Igor Druzhinin --- drivers/xen/pci.c | 21 +++++++++++++++------ 1 file changed, 15 insertions(+), 6 deletions(-) diff --git a/drivers/xen/pci.c b/drivers/xen/pci.c index 7494dbe..db58aaa 100644 --- a/drivers/xen/pci.c +++ b/drivers/xen/pci.c @@ -29,6 +29,8 @@ #include "../pci/pci.h" #ifdef CONFIG_PCI_MMCONFIG #include + +static int xen_mcfg_late(void); #endif static bool __read_mostly pci_seg_supported = true; @@ -40,7 +42,18 @@ static int xen_add_device(struct device *dev) #ifdef CONFIG_PCI_IOV struct pci_dev *physfn = pci_dev->physfn; #endif - +#ifdef CONFIG_PCI_MMCONFIG + static bool pci_mcfg_reserved = false; + /* + * Reserve MCFG areas in Xen on first invocation due to this being + * potentially called from inside of acpi_init immediately after + * MCFG table has been finally parsed. + */ + if (!pci_mcfg_reserved) { + xen_mcfg_late(); + pci_mcfg_reserved = true; + } +#endif if (pci_seg_supported) { struct { struct physdev_pci_device_add add; @@ -213,7 +226,7 @@ static int __init register_xen_pci_notifier(void) arch_initcall(register_xen_pci_notifier); #ifdef CONFIG_PCI_MMCONFIG -static int __init xen_mcfg_late(void) +static int xen_mcfg_late(void) { struct pci_mmcfg_region *cfg; int rc; @@ -252,8 +265,4 @@ static int __init xen_mcfg_late(void) } return 0; } -/* - * Needs to be done after acpi_init which are subsys_initcall. - */ -subsys_initcall_sync(xen_mcfg_late); #endif -- 2.7.4