linux-kernel - Re: Subject: [PATCH] x86/pci: Detect mmconfig on nVidia MCP55 -v2

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:	Tue, 10 Feb 2009 21:05:21 -0800
From:	Yinghai Lu <yinghai@...nel.org>
To:	Ed Swierk <eswierk@...stanetworks.com>
Cc:	jbarnes@...tuousgeek.org, Ingo Molnar <mingo@...e.hu>,
	hpa@...or.com, linux-kernel@...r.kernel.org,
	linux-pci@...r.kernel.org
Subject: Re: Subject: [PATCH] x86/pci: Detect mmconfig on nVidia MCP55 -v2

On Tue, Feb 10, 2009 at 2:57 PM, Ed Swierk <eswierk@...stanetworks.com> wrote:
> On Mon, Feb 9, 2009 at 6:00 PM, Yinghai Lu <yinghai@...nel.org> wrote:
>> From: Ed Swierk <eswierk@...stanetworks.com>
>>
>> Detect and enable memory-mapped PCI configuration space on the nVidia
>> MCP55 southbridge.  Tested against 2.6.27.4 on an Arista Networks
>> development board with one MCP55, Coreboot firmware, no ACPI.
>>
>> v2: add multi mcp55 support, and conexist with amd quad core system by Yinghai
>>    also only enable it only when acpi=off or acpi is not built-in
>>
>> Signed-off-by: Ed Swierk <eswierk@...stanetworks.com>
>
> A couple of comments below. Let me test this version before signing off.
>
>> Signed-off-by: Yinghai Lu <yinghai@...nel.org>
>>
>> ---
>>  arch/x86/pci/mmconfig-shared.c |   64 +++++++++++++++++++++++++++++++++++++++++
>>  1 file changed, 64 insertions(+)
>>
>> Index: linux-2.6/arch/x86/pci/mmconfig-shared.c
>> ===================================================================
>> --- linux-2.6.orig/arch/x86/pci/mmconfig-shared.c
>> +++ linux-2.6/arch/x86/pci/mmconfig-shared.c
>> @@ -166,6 +166,68 @@ static const char __init *pci_mmcfg_amd_
>>        return "AMD Family 10h NB";
>>  }
>>
>> +static bool __initdata mcp55_checked;
>> +static const char __init *pci_mmcfg_nvidia_mcp55(void)
>> +{
>> +       int bus;
>> +       int mcp55_mmconf_found = 0;
>> +
>> +       static const u32 extcfg_regnum          = 0x90;
>> +       static const u32 extcfg_regsize         = 4;
>> +       static const u32 extcfg_enable_mask     = 1<<31;
>> +       static const u32 extcfg_start_mask      = 0xff<<16;
>> +       static const int extcfg_start_shift     = 16;
>> +       static const u32 extcfg_size_mask       = 0x3<<28;
>> +       static const int extcfg_size_shift      = 28;
>> +       static const int extcfg_sizebus[]       = {0x100, 0x80, 0x40, 0x20};
>> +       static const u32 extcfg_base_mask[]     = {0x7ff8, 0x7ffc, 0x7ffe, 0x7fff};
>> +       static const int extcfg_base_lshift     = 25;
>> +
>> +       /*
>> +        * do check if amd fam10h already took over
>> +        */
>> +       if (!acpi_disabled || pci_mmcfg_config_num || mcp55_checked)
>> +               return NULL;
>
> Why skip this if !acpi_disabled? I thought we want to have the host
> bridge mmconfig settings override the ACPI MCFG. At least that appears
> to be the logic for other host bridges.

try to make thing simple.
for system: with AMD Fam10h, and MCP55 + 2 IO55
amd fam10h cpu: said it needs [0,0]
mcp55: said it need [0,255]
io55 #1: said it need [0x40, 0x40+255], then u8 end_bus_number = 0x3f
io55 #2: said it need [0x80, 0x80+255], then u8 end_bus_number = 0x7f
MMIO route in NBs is right.

but MCFG is right... so just use that.

when acpi=off, if check_and_enable_amd_mconf, it will forcely to make
amd fam10h cpu: said it needs [0,255] and pci_mmcfg_config_num = 1
so mcp55 mconf is not used.


>
>> +       mcp55_checked = true;
>> +       for (bus = 0; bus < 256; bus++) {
>> +               u64 base;
>> +               u32 l, extcfg;
>> +               u16 vendor, device;
>> +               int start, size_index, end;
>> +
>> +               raw_pci_ops->read(0, bus, PCI_DEVFN(0, 0), 0, 4, &l);
>
> Don't we need to check devices 8, 16 and 24 as well as 0?

you didn't put mcp55 on device 0? why?

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