lkml.org 
[lkml]   [2010]   [Sep]   [15]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [PATCH 3/3] PCI: allocate bus resources from the top down
On 09/15/2010 03:44 PM, Bjorn Helgaas wrote:
>
> 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.
>

If we put PCI devices in E820 RESERVED areas that's a bug, plain and
simple. We should absolutely not doing so!

To some degree I don't care if Windows does or not ... that is the
documented mechanism for reserving address space, and we should respect
that. Furthermore, we use the same mechanism internally for reserving
address space.

Furthermore, the only potentially bad outcome is reserving excessive
address space, which is in general safer than the opposite.

So let's just fix this.

-hpa


\
 
 \ /
  Last update: 2010-09-16 01:49    [W:0.042 / U:1.016 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site