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

[H. Peter Anvin]

On 09/16/2010 10:04 AM, Bjorn Helgaas wrote:
> It does seem like we should do *something* with E820 reserved areas, but
> I'm not 100% convinced we should be more strict than Windows.  If we
> pay attention to things Windows doesn't test, I think we're likely to
> trip over even more BIOS bugs.

Windows have a couple of advantages on us.  They have WHQL; every
machine needs to pass WHQL or it doesn't get sold.  The other advantage
is that most manufacturers of Windows desktops don't give a damn about
anything other than the shipping configuration (Windows version and
hardware): I have seen machines which fail to boot if you put in a PCI
UART card.

> Linux does avoid putting PCI devices in E820 reserved areas ... in
> some cases.  In this Dell case, the reserved area conflicts with a
> host bridge window, so we expand the reserved area and insert it as
> the *parent* of the window.  Since it's the parent, it has no effect
> on allocations from the window, so we end up putting devices in the
> reserved area.

OK, so that's a problem.  This isn't really a hideously uncommon use
case for a reserved region, either: it probably reflects a device used
by SMM under that particular host bridge.

> I think the problem is that E820 reservations fundamentally don't
> fit well with the Linux resource manager.  We manage resources as
> a strict hierarchy of non-overlapping regions, but there's no
> requirement that E820 reservations have any relationship with actual
> devices that we discover via ACPI, PCI, etc.
> 
> We've been kludging around this with a collection of hacks like
> reserve_region_with_split() and insert_resource_expand_to_fit(),
> but I think we're just making an unmaintainable mess.  We should
> take a step back and think about how to do this cleanly.

Perhaps we should consider reserved regions a separate hierarchy, or we
should deal with them at the time a new resource is created?

	-hpa

-- 
H. Peter Anvin, Intel Open Source Technology Center
I work for Intel.  I don't speak on their behalf.

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/