linux-kernel - Re: Are these MTRR settings correct?

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: Windows password security audit tool. GUI, reports in PDF.

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

Date:	Mon, 14 Dec 2009 19:22:15 -0600
From:	Robert Hancock <hancockrwd@...il.com>
To:	Yinghai Lu <yinghai@...nel.org>
CC:	Tvrtko Ursulin <tvrtko@...ulin.net>,
	Tvrtko Ursulin <tvrtko.ursulin@...hos.com>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	Jesse Barnes <jbarnes@...tuousgeek.org>
Subject: Re: Are these MTRR settings correct?

On 12/14/2009 02:26 PM, Yinghai Lu wrote:
> Tvrtko Ursulin wrote:
>> On Monday 14 Dec 2009 19:47:40 Yinghai Lu wrote:
>>> Tvrtko Ursulin wrote:
>>>> On Monday 14 Dec 2009 11:25:58 Yinghai Lu wrote:
>>>>>>> something wrong, we should not check that with e820 or acpi resource
>>>>>>> in that case. please check
>>>>>>>
>>>>>>> {PATCH] x86/pci: don't check mmconf again if it is from MSR with amd
>>>>>>> faml0h
>>>>>>>
>>>>>>> for AMD Fam10h, it we read mmconf from MSR early, we should just trust
>>>>>>> it because we check it and correct it already.
>>>>>>>
>>>>>>> so skip the reject check there.
>>>>>> [path snipped]
>>>>>>
>>>>>> Do you want me to test with this patch and that pci=.. option active
>>>>>> and post dmesg? Or without the pci=... option?
>>>>> with this patch and pci=... and post dmesg...
>>>> Here you go:
>>> ...
>>>
>>>> [    0.250041] node 0 link 0: io port [1000, ffffff]
>>>> [    0.250043] TOM: 00000000e0000000 aka 3584M
>>>> [    0.250044] Fam 10h mmconf [e0000000, efffffff]
>>>> [    0.250046] node 0 link 0: mmio [a0000, bffff]
>>>> [    0.250048] node 0 link 0: mmio [e0000000, efffffff] ==>  none
>>>> [    0.250050] node 0 link 0: mmio [f0000000, fe7fffff]
>>>> [    0.250051] node 0 link 0: mmio [fe800000, fe9fffff]
>>>> [    0.250053] node 0 link 0: mmio [fea00000, ffefffff]
>>>> [    0.250054] TOM2: 0000000120000000 aka 4608M
>>>> [    0.250056] bus: [00,07] on node 0 link 0
>>>> [    0.250057] bus: 00 index 0 io port: [0, ffff]
>>>> [    0.250058] bus: 00 index 1 mmio: [a0000, bffff]
>>>> [    0.250060] bus: 00 index 2 mmio: [f0000000, ffffffff]
>>>> [    0.250061] bus: 00 index 3 mmio: [120000000, fcffffffff]
>>>> [    0.250068] ACPI: bus type pci registered
>>>> [    0.250091] PCI: Found AMD Family 10h NB with MMCONFIG support.
>>>> [    0.254793] PCI: Using MMCONFIG at e0000000 - efffffff
>>>> [    0.254795] PCI: Using configuration type 1 for base access
>>> ...
>>>
>>> thanks, mmconf works on your system.
>>
>> So I should keep using both your patch and pci=check_enable_amd_mmconf option?
>>
>
> I will push the driver to Jesse.
>
> but you need to have pci=check_enable_amd_mmconf, unless we add one DMI entry for your kind of system.

Something else isn't quite right. It looks like MMCONFIG area should be 
reserved:

[    0.308434] system 00:0c: iomem range 0xe0000000-0xefffffff has been 
reserved

but the code didn't seem to detect that. In fact there doesn't seem to 
be any output about whether it was or wasn't reserved, which from the 
code it seems there should be.

Maybe because of that ACPI method execution error?


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