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]

Message-Id: <200912150955.03974.bjorn.helgaas@hp.com>
Date:	Tue, 15 Dec 2009 09:55:03 -0700
From:	Bjorn Helgaas <bjorn.helgaas@...com>
To:	Yinghai Lu <yinghai@...nel.org>
Cc:	Robert Hancock <hancockrwd@...il.com>,
	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 Monday 14 December 2009 06:42:11 pm Yinghai Lu wrote:
> Robert Hancock wrote:
> > 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?
> 
> could be sth pnpacpi brokenness?

Robert, I assume you're referring to this from Tvrtko's post
(http://lkml.org/lkml/2009/12/13/90):

[    0.000000]  BIOS-e820: 00000000dffd0000 - 00000000e0000000 (reserved)
[    0.000000]  BIOS-e820: 00000000ff700000 - 0000000100000000 (reserved)
...
[    0.250088] PCI: Found AMD Family 10h NB with MMCONFIG support.
[    0.250091] PCI: MCFG configuration 0: base e0000000 segment 0 buses 0 - 255
[    0.250092] PCI: Not using MMCONFIG.
...
[    0.253491] ACPI Error (psargs-0359): [ECEN] Namespace lookup failure, AE_NOT_FOUND
[    0.253495] ACPI Error (psparse-0537): Method parse/execution failed [\] (Node ffffffff81656ab0), AE_NOT_FOUND
...
[    0.308434] system 00:0c: iomem range 0xe0000000-0xefffffff has been reserved

I think we're rejecting MMCONFIG in the early call to
pci_mmcfg_reject_broken(), when we check only E820 resources, not
ACPI resources.  And indeed, the 0xe0000000-0xefffffff range is
not mentioned in E820.  Which output did you expect to see?

I am uncomfortable with this early/late checking and looking at both
E820 and ACPI.  It just feels hacky and error-prone.  I'm not happy about
adding Yinghai's special-case "if we found AMD Fam10h, don't check for
reservations" patch either.

I assume that Windows runs on this box without requiring per-machine
hacks in the kernel.  Linux should be able to do the same, and the fact
that we can't is telling us we're doing somethign wrong.  We should fix
whatever's wrong rather than papering over it.

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/