linux-kernel - Re: [PATCH 3/3] PCI: allocate bus resources from the top down

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:	Wed, 15 Sep 2010 16:44:37 -0600
From:	Bjorn Helgaas <bjorn.helgaas@...com>
To:	"H. Peter Anvin" <hpa@...or.com>
Cc:	Jesse Barnes <jbarnes@...tuousgeek.org>,
	Brian Bloniarz <phunge0@...mail.com>,
	Charles Butterfield <charles.butterfield@...tcentury.com>,
	Denys Vlasenko <dvlasenk@...hat.com>,
	linux-pci@...r.kernel.org, linux-kernel@...r.kernel.org,
	Stefan Becker <chemobejk@...il.com>,
	Yinghai Lu <yinghai@...nel.org>,
	Thomas Gleixner <tglx@...utronix.de>,
	Linus Torvalds <torvalds@...ux-foundation.org>,
	Ingo Molnar <mingo@...e.hu>
Subject: Re: [PATCH 3/3] PCI: allocate bus resources from the top down

On Wednesday, September 15, 2010 03:50:14 pm H. Peter Anvin wrote:
> On 09/15/2010 02:09 PM, Bjorn Helgaas wrote:
> > 
> > On the machine above (a Dell T3500), the [mem 0xbff00000-0xbfffffff] region
> > doesn't actually work and is likely a BIOS defect.  The symptom is that we
> > move the AHCI controller to 0xbff00000, which leads to "Boot has failed,
> > sleeping forever," a BUG in ahci_stop_engine(), or some other boot failure.
> > 
> 
> Acked-by: H. Peter Anvin <hpa@...or.com>
> 
> ... for the patch in general, but I would like to *also* request a DMA
> or PCI quirk to explicitly reserve the above range on the affected Dell
> machines.

I'd like to do that, but I don't see a good way to do it yet.

We saw the problem on a T3500, a T3400, and a T4500, and I'm sure there
are others.  So I don't know how to identify the affected machines.

And I don't know how to identify the invalid ranges, because I suspect
it depends on the memory size.  I think it would be quite unusual for
a window to start 1MB under the nice 256MB boundary, but I'm not sure
I'm ready to say that's always illegal.

On these machines, the [mem 0xbff00000-0xbfffffff] area is actually
reported as reserved in the E820 map, and I first thought we could
simply rely on that.  But I'm not really comfortable with that either,
because I don't think there's a dependable relationship between those
E820 entries and ACPI and PCI devices.  For one thing, I experimented
with Windows, and it happily places PCI devices in reserved areas,
and I think we're likely to trip over more BIOS bugs if we rely on
something Windows doesn't.

I suspect Windows would blow up, too, if we could somehow fill up the
rest of the window and force it to allocate the bottom.  But since
it's only a 1MB area, I think that would be very difficult to do
unless there's some way to tweak PCI BARs before booting Windows.

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/