Re: [RFC] Runtime allocation of PCI resources

[Andi Kleen <andi@firstfloor.org>]

Matthew Garrett <mjg59@srcf.ucam.org> writes:

> BIOS authors don't always program all the features of hardware. This is 
> often the case for Intel IDE controllers, which are usually able to run 
> in AHCI mode but are rarely configured to do so. Reprogramming them is 
> easy enough other than the requirement for some MMIO space. If the BIOS 
> hasn't allocated this, it's necessary for us to do so manually.

Traditionally we've had bad experiences forcing hardware to do something
the BIOS didn't consider. e.g. occasionally the BIOS has good reasons
to not allow it; maybe it knows about some errata or other problem
the kernel doesn't. 

If you do this then don't make it default at least, but only allow
to force it use an option.
 
> This patch simply attempts to find some free address space and allocate 
> it. The function is designed to be called after the rest of the 
> resources have been allocated in order to avoid colliding with other 
> devices.
> 
> This seems to work fine on x86, but I'm happy to admit that I know 
> little about the intricacies of how PCI is implemented elsewhere. Is 
> this approach valid in the general case? I'm also working on the 
> assumption that the firmware will program hotplug PCI hardware in a way 
> that isn't going to end up colliding with this. Anyway, any 
> thoughts/comments?

I tried something similar some time ago for the IOMMU aperture.
It turned out that some systems put something into the e820 holes
and didn't boot anymore if you put something else in there.
Your resource allocation will just do that.

You might be lucky because your resources are typically
small (IOMMU aperture was 64+MB) or you might not.

These problems are unfortunately very hard to debug; typically
you have to bisect.

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