linux-kernel - Re: [PATCH V5 3/4] x86/PCI: Stop enabling ECS for AMD CPUs after Fam16h

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

Hash Suite for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Thu, 22 May 2014 11:56:03 -0600
From:	Bjorn Helgaas <bhelgaas@...gle.com>
To:	Borislav Petkov <bp@...en8.de>
Cc:	Suravee Suthikulpanit <Suravee.Suthikulpanit@....com>,
	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 Wed, May 21, 2014 at 5:38 PM, Borislav Petkov <bp@...en8.de> wrote:
> On Wed, May 21, 2014 at 05:18:17PM -0600, Bjorn Helgaas wrote:
>> ECS is an AMD mechanism that allows access to extended PCI config space
>> (offsets 256-4096) via I/O ports CF8/CFCh.  We normally use ECAM, i.e.,
>> MMCONFIG, to access that space, but apparently old machines have issues
>> that meant we couldn't use ECAM.
>>
>> The solution was to enable ECS so we could use configuration mechanism #1
>> (I/O ports CF8/CFCh) to access extended config space.  See 831d991821da
>> ("x86: add PCI extended config space access for AMD Barcelona").
>>
>> New machines should be able to use ECAM, which means they don't need the
>> CPU-specific code to enable ECS.  This patch leaves ECS the same on all
>> existing platforms, but stops enabling it on platforms after Fam16h.
>>
>> Those future platforms should be able to use the standard ACPI MCFG/_CBA
>> descriptions of the PCIe ECAM mechanism.
>>
>> Signed-off-by: Bjorn Helgaas <bhelgaas@...gle.com>
>> CC: Robert Richter <rric@...nel.org>
>> ---
>>  arch/x86/pci/amd_bus.c |    4 +++-
>>  1 file changed, 3 insertions(+), 1 deletion(-)
>>
>> diff --git a/arch/x86/pci/amd_bus.c b/arch/x86/pci/amd_bus.c
>> index aa936e3a2019..67dadf179348 100644
>> --- a/arch/x86/pci/amd_bus.c
>> +++ b/arch/x86/pci/amd_bus.c
>> @@ -405,7 +405,9 @@ static int __init amd_postcore_init(void)
>>               return 0;
>>
>>       early_fill_mp_bus_info();
>> -     pci_io_ecs_init();
>> +
>> +     if (boot_cpu_data.x86 <= 0x16)
>
> Fam 0x16, i.e. hex? I think we talked about fam 0x10, i.e. 16 decimal.
>
> Oh well, that's an AMD call now.

I chose Fam16h (0x16) because it looks like that's the newest stuff
that's in the field.  I suspect things would probably work if we
changed this patch to leave ECS disabled on some Fam16h, Fam15h, etc.,
but that would change behavior on existing systems, which obviously
adds some risk.  I didn't think there was much benefit that makes the
risk worthwhile.

My goal is to stop needing CPU-specific changes in the future, not
necessarily to remove the CPU-specific code we already have.

Does that make sense?  I'm not sure whether I understood your real question.

Bjorn
--
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/