From owner-svn-src-all@freebsd.org Tue Apr 9 18:07:19 2019 Return-Path: Delivered-To: svn-src-all@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 543851567C93; Tue, 9 Apr 2019 18:07:19 +0000 (UTC) (envelope-from kib@FreeBSD.org) Received: from mxrelay.nyi.freebsd.org (mxrelay.nyi.freebsd.org [IPv6:2610:1c1:1:606c::19:3]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) server-signature RSA-PSS (4096 bits) client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "mxrelay.nyi.freebsd.org", Issuer "Let's Encrypt Authority X3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id EA2E671516; Tue, 9 Apr 2019 18:07:18 +0000 (UTC) (envelope-from kib@FreeBSD.org) Received: from repo.freebsd.org (repo.freebsd.org [IPv6:2610:1c1:1:6068::e6a:0]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mxrelay.nyi.freebsd.org (Postfix) with ESMTPS id C56BDEB9C; Tue, 9 Apr 2019 18:07:18 +0000 (UTC) (envelope-from kib@FreeBSD.org) Received: from repo.freebsd.org ([127.0.1.37]) by repo.freebsd.org (8.15.2/8.15.2) with ESMTP id x39I7Iok008280; Tue, 9 Apr 2019 18:07:18 GMT (envelope-from kib@FreeBSD.org) Received: (from kib@localhost) by repo.freebsd.org (8.15.2/8.15.2/Submit) id x39I7Haf008276; Tue, 9 Apr 2019 18:07:17 GMT (envelope-from kib@FreeBSD.org) Message-Id: <201904091807.x39I7Haf008276@repo.freebsd.org> X-Authentication-Warning: repo.freebsd.org: kib set sender to kib@FreeBSD.org using -f From: Konstantin Belousov Date: Tue, 9 Apr 2019 18:07:17 +0000 (UTC) To: src-committers@freebsd.org, svn-src-all@freebsd.org, svn-src-head@freebsd.org Subject: svn commit: r346062 - in head/sys: amd64/pci i386/pci x86/include x86/x86 X-SVN-Group: head X-SVN-Commit-Author: kib X-SVN-Commit-Paths: in head/sys: amd64/pci i386/pci x86/include x86/x86 X-SVN-Commit-Revision: 346062 X-SVN-Commit-Repository: base MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-Rspamd-Queue-Id: EA2E671516 X-Spamd-Bar: -- Authentication-Results: mx1.freebsd.org X-Spamd-Result: default: False [-2.95 / 15.00]; local_wl_from(0.00)[FreeBSD.org]; NEURAL_HAM_MEDIUM(-0.99)[-0.994,0]; NEURAL_HAM_LONG(-1.00)[-1.000,0]; NEURAL_HAM_SHORT(-0.96)[-0.961,0]; ASN(0.00)[asn:11403, ipnet:2610:1c1:1::/48, country:US] X-BeenThere: svn-src-all@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "SVN commit messages for the entire src tree \(except for " user" and " projects" \)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Apr 2019 18:07:19 -0000 Author: kib Date: Tue Apr 9 18:07:17 2019 New Revision: 346062 URL: https://svnweb.freebsd.org/changeset/base/346062 Log: pci_cfgreg.c: Use io port config access for early boot time. Some early PCIe chipsets are explicitly listed in the white-list to enable use of the MMIO config space accesses, perhaps because ACPI tables were not reliable source of the base MCFG address at that time. For that chipsets, MCFG base was read from the known chipset MCFGbase config register. During very early stage of boot, when access to the PCI config space is performed (see e.g. pci_early_quirks.c), we cannot map 255MB of registers because the method used with pre-boot pmap overflows initial kernel page tables. Move fallback to read MCFGbase to the attachment method of the x86/legacy device, which removes code duplication, and results in the use of io accesses until MCFG is parsed or legacy attach called. For amd64, pre-initialize cfgmech with CFGMECH_1, right now we dynamically assign CFGMECH_1 to it anyway, and remove checks for CFGMECH_NONE. There is a mention in the Intel documentation for corresponding chipsets that OS must use either io port or MMIO access method, but we already break this rule by reading MCFGbase register, so one more access seems to be innocent. Reported by: longwitz@incore.de PR: 236838 Reviewed by: avg (other version), jhb Sponsored by: The FreeBSD Foundation MFC after: 1 week Differential revision: https://reviews.freebsd.org/D19833 Modified: head/sys/amd64/pci/pci_cfgreg.c head/sys/i386/pci/pci_cfgreg.c head/sys/x86/include/pci_cfgreg.h head/sys/x86/x86/legacy.c Modified: head/sys/amd64/pci/pci_cfgreg.c ============================================================================== --- head/sys/amd64/pci/pci_cfgreg.c Tue Apr 9 17:52:11 2019 (r346061) +++ head/sys/amd64/pci/pci_cfgreg.c Tue Apr 9 18:07:17 2019 (r346062) @@ -44,12 +44,6 @@ __FBSDID("$FreeBSD$"); #include #include -enum { - CFGMECH_NONE = 0, - CFGMECH_1, - CFGMECH_PCIE, -}; - static uint32_t pci_docfgregread(int bus, int slot, int func, int reg, int bytes); static int pciereg_cfgread(int bus, unsigned slot, unsigned func, @@ -61,7 +55,13 @@ static void pcireg_cfgwrite(int bus, int slot, int fun SYSCTL_DECL(_hw_pci); -static int cfgmech; +/* + * For amd64 we assume that type 1 I/O port-based access always works. + * If an ACPI MCFG table exists, pcie_cfgregopen() will be called to + * switch to memory-mapped access. + */ +int cfgmech = CFGMECH_1; + static vm_offset_t pcie_base; static int pcie_minbus, pcie_maxbus; static uint32_t pcie_badslots; @@ -71,47 +71,10 @@ static int mcfg_enable = 1; SYSCTL_INT(_hw_pci, OID_AUTO, mcfg, CTLFLAG_RDTUN, &mcfg_enable, 0, "Enable support for PCI-e memory mapped config access"); -/* - * Initialise access to PCI configuration space - */ int pci_cfgregopen(void) { - uint64_t pciebar; - uint16_t did, vid; - if (cfgmech != CFGMECH_NONE) - return (1); - cfgmech = CFGMECH_1; - - /* - * Grope around in the PCI config space to see if this is a - * chipset that is capable of doing memory-mapped config cycles. - * This also implies that it can do PCIe extended config cycles. - */ - - /* Check for supported chipsets */ - vid = pci_cfgregread(0, 0, 0, PCIR_VENDOR, 2); - did = pci_cfgregread(0, 0, 0, PCIR_DEVICE, 2); - switch (vid) { - case 0x8086: - switch (did) { - case 0x3590: - case 0x3592: - /* Intel 7520 or 7320 */ - pciebar = pci_cfgregread(0, 0, 0, 0xce, 2) << 16; - pcie_cfgregopen(pciebar, 0, 255); - break; - case 0x2580: - case 0x2584: - case 0x2590: - /* Intel 915, 925, or 915GM */ - pciebar = pci_cfgregread(0, 0, 0, 0x48, 4); - pcie_cfgregopen(pciebar, 0, 255); - break; - } - } - return (1); } @@ -135,9 +98,6 @@ pci_cfgregread(int bus, int slot, int func, int reg, i { uint32_t line; - if (cfgmech == CFGMECH_NONE) - return (0xffffffff); - /* * Some BIOS writers seem to want to ignore the spec and put * 0 in the intline rather than 255 to indicate none. Some use @@ -161,9 +121,6 @@ pci_cfgregread(int bus, int slot, int func, int reg, i void pci_cfgregwrite(int bus, int slot, int func, int reg, u_int32_t data, int bytes) { - - if (cfgmech == CFGMECH_NONE) - return; if (cfgmech == CFGMECH_PCIE && (bus >= pcie_minbus && bus <= pcie_maxbus) && Modified: head/sys/i386/pci/pci_cfgreg.c ============================================================================== --- head/sys/i386/pci/pci_cfgreg.c Tue Apr 9 17:52:11 2019 (r346061) +++ head/sys/i386/pci/pci_cfgreg.c Tue Apr 9 18:07:17 2019 (r346062) @@ -64,20 +64,13 @@ struct pcie_cfg_elem { vm_paddr_t papage; }; -enum { - CFGMECH_NONE = 0, - CFGMECH_1, - CFGMECH_2, - CFGMECH_PCIE, -}; - SYSCTL_DECL(_hw_pci); static TAILQ_HEAD(pcie_cfg_list, pcie_cfg_elem) pcie_list[MAXCPU]; static uint64_t pcie_base; static int pcie_minbus, pcie_maxbus; static uint32_t pcie_badslots; -static int cfgmech; +int cfgmech; static int devmax; static struct mtx pcicfg_mtx; static int mcfg_enable = 1; @@ -136,10 +129,8 @@ pcibios_get_version(void) int pci_cfgregopen(void) { - static int opened = 0; - uint64_t pciebar; - u_int16_t vid, did; - u_int16_t v; + uint16_t v; + static int opened = 0; if (opened) return (1); @@ -158,38 +149,7 @@ pci_cfgregopen(void) if (v >= 0x0210) pci_pir_open(); - if (cfgmech == CFGMECH_PCIE) - return (1); - - /* - * Grope around in the PCI config space to see if this is a - * chipset that is capable of doing memory-mapped config cycles. - * This also implies that it can do PCIe extended config cycles. - */ - - /* Check for supported chipsets */ - vid = pci_cfgregread(0, 0, 0, PCIR_VENDOR, 2); - did = pci_cfgregread(0, 0, 0, PCIR_DEVICE, 2); - switch (vid) { - case 0x8086: - switch (did) { - case 0x3590: - case 0x3592: - /* Intel 7520 or 7320 */ - pciebar = pci_cfgregread(0, 0, 0, 0xce, 2) << 16; - pcie_cfgregopen(pciebar, 0, 255); - break; - case 0x2580: - case 0x2584: - case 0x2590: - /* Intel 915, 925, or 915GM */ - pciebar = pci_cfgregread(0, 0, 0, 0x48, 4); - pcie_cfgregopen(pciebar, 0, 255); - break; - } - } - - return(1); + return (1); } static uint32_t Modified: head/sys/x86/include/pci_cfgreg.h ============================================================================== --- head/sys/x86/include/pci_cfgreg.h Tue Apr 9 17:52:11 2019 (r346061) +++ head/sys/x86/include/pci_cfgreg.h Tue Apr 9 18:07:17 2019 (r346062) @@ -48,6 +48,15 @@ #define CONF2_ENABLE_CHK 0x0e #define CONF2_ENABLE_RES 0x0e +enum { + CFGMECH_NONE = 0, + CFGMECH_1, + CFGMECH_2, + CFGMECH_PCIE, +}; + +extern int cfgmech; + rman_res_t hostb_alloc_start(int type, rman_res_t start, rman_res_t end, rman_res_t count); int pcie_cfgregopen(uint64_t base, uint8_t minbus, uint8_t maxbus); int pci_cfgregopen(void); Modified: head/sys/x86/x86/legacy.c ============================================================================== --- head/sys/x86/x86/legacy.c Tue Apr 9 17:52:11 2019 (r346061) +++ head/sys/x86/x86/legacy.c Tue Apr 9 18:07:17 2019 (r346062) @@ -46,8 +46,10 @@ __FBSDID("$FreeBSD$"); #include #include #include +#include #include +#include #include #include @@ -111,10 +113,52 @@ legacy_probe(device_t dev) return (0); } +/* + * Grope around in the PCI config space to see if this is a chipset + * that is capable of doing memory-mapped config cycles. This also + * implies that it can do PCIe extended config cycles. + */ +static void +legacy_pci_cfgregopen(device_t dev) +{ + uint64_t pciebar; + u_int16_t did, vid; + + if (cfgmech == CFGMECH_NONE || cfgmech == CFGMECH_PCIE) + return; + + /* Check for supported chipsets */ + vid = pci_cfgregread(0, 0, 0, PCIR_VENDOR, 2); + did = pci_cfgregread(0, 0, 0, PCIR_DEVICE, 2); + switch (vid) { + case 0x8086: + switch (did) { + case 0x3590: + case 0x3592: + /* Intel 7520 or 7320 */ + pciebar = pci_cfgregread(0, 0, 0, 0xce, 2) << 16; + pcie_cfgregopen(pciebar, 0, 255); + break; + case 0x2580: + case 0x2584: + case 0x2590: + /* Intel 915, 925, or 915GM */ + pciebar = pci_cfgregread(0, 0, 0, 0x48, 4); + pcie_cfgregopen(pciebar, 0, 255); + break; + } + } + + if (bootverbose && cfgmech == CFGMECH_PCIE) + device_printf(dev, "Enabled ECAM PCIe accesses\n"); +} + static int legacy_attach(device_t dev) { device_t child; + + legacy_pci_cfgregopen(dev); /* * Let our child drivers identify any child devices that they