lists.openwall.net | lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC | |
Open Source and information security mailing list archives
| ||
|
Date: Fri, 23 May 2014 19:31:28 -0500 From: Suravee Suthikulanit <suravee.suthikulpanit@....com> To: Bjorn Helgaas <bhelgaas@...gle.com> CC: Borislav Petkov <bp@...en8.de>, Robert Richter <rric@...nel.org>, "Daniel J Blueman" <daniel@...ascale.com>, Andreas Herrmann <herrmann.der.user@...glemail.com>, "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>, Aravind Gopalakrishnan <Aravind.Gopalakrishnan@....com>, "linux-pci@...r.kernel.org" <linux-pci@...r.kernel.org>, Borislav Petkov <bp@...e.de>, Myron Stowe <myron.stowe@...hat.com> Subject: Re: [PATCH V5 3/4] x86/PCI: Stop enabling ECS for AMD CPUs after Fam16h On 5/22/2014 9:54 PM, Bjorn Helgaas wrote: > I've been poking around for recent dmesg logs that contain "PCI: Using > configuration type 1 for extended access", and there are quite a few. > In most cases there*is* an MCFG table, but apparently we decide not > to use it for some reason (unfortunately we don't print the specific > reason). One example is at > https://bugzilla.kernel.org/show_bug.cgi?id=68591 . > > I'm going to go out on a limb and guess that Windows does not enable > ECS, so it probably uses ECAM. Therefore, I suspect Linux's parsing > of MCFG is broken in some way, and we probably*could* use ECAM in all > these cases I'm seeing. > > It would probably be prudent to figure out why Linux is rejecting > these MCFG tables. We'll probably see similar tables on Fam17h > systems, and if we continue rejecting them, and we don't turn on ECS, > we won't be able to access extended config space. > > I opened a bugzilla for this issue: > https://bugzilla.kernel.org/show_bug.cgi?id=76771 > > I'm wavering on whether it's a good idea to put this patch in before > understanding the issue. As much as I'd like to stop fiddling with > ECS, we'd likely end up with a v3.15 where extended config space > doesn't work on some Fam17h systems. So, I have located a system which presents issue with MMCONFIG. Here is my investigation: DEBUG: pci_io_ecs_init: pci_probe = 4000f ACPI: bus type PCI registered DEBUG: -----> pci_mmcfg_early_init DEBUG: pci_parse_mcfg PCI: MMCONFIG for domain 0000 [bus 00-01] at [mem 0xe0000000-0xe01fffff] (base 0xe0000000) DEBUG: pci_mmcfg_check_reserved DEBUG: is_mmconf_reserved: method = E820 PCI: not using MMCONFIG DEBUG: pci_direct_init PCI: Using configuration type 1 for base access PCI: Using configuration type 1 for extended access ACPI: Added _OSI(Module Device) ACPI: Added _OSI(Processor Device) ACPI: Added _OSI(3.0 _SCP Extensions) ACPI: Added _OSI(Processor Aggregator Device) [Firmware Bug]: ACPI: BIOS _OSI(Linux) query ignored \_SB_:_OSC invalid UUID _OSC request data:1 1f ACPI: Interpreter enabled ACPI Exception: AE_NOT_FOUND, While evaluating Sleep State [\_S1_] (20140214/hwxface-580) ACPI Exception: AE_NOT_FOUND, While evaluating Sleep State [\_S2_] (20140214/hwxface-580) ACPI Exception: AE_NOT_FOUND, While evaluating Sleep State [\_S4_] (20140214/hwxface-580) ACPI: (supports S0 S3 S5) ACPI: Using IOAPIC for interrupt routing DEBUG: ----> pci_mmcfg_late_init DEBUG: pci_parse_mcfg PCI: MMCONFIG for domain 0000 [bus 00-01] at [mem 0xe0000000-0xe01fffff] (base 0xe0000000) DEBUG: pci_mmcfg_check_reserved DEBUG: is_mmconf_reserved: method = ACPI motherboard resources PCI: MMCONFIG at [mem 0xe0000000-0xe01fffff] reserved in ACPI motherboard resources During pci_mmcfg_early_init(), the MMCONFIG failed because the range 0xe0000000 is not showing as reserved in the E820 mapping. Here is the snippet of E820 mapping from the system: ........ BIOS-e820: [mem 0x00000000c7eb0000-0x00000000c7ec0fff] ACPI data BIOS-e820: [mem 0x00000000c7ec1000-0x00000000c7ec2fff] ACPI NVS BIOS-e820: [mem 0x00000000c7ec3000-0x00000000c7efefff] reserved BIOS-e820: [mem 0x00000000c7f00000-0x00000000c7ffffff] reserved BIOS-e820: [mem 0x00000000fec00000-0x00000000fec0ffff] reserved However, during pci_mmcfg_late_init(), the area is reserved in the "ACPI motherboard resources", and the pci_mmcfg_check_reserved() does not fail here. But this is too late since we already setup the "raw_pci_ext_ops" in the "arch/x86/pci/direct.c: pci_direct_init()" (during to use the IO_ECS. Suravee -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@...r.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists