linux-kernel - Re: [RFC] Runtime allocation of PCI resources

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:	11 Jun 2007 20:11:24 +0200
From:	Andi Kleen <andi@...stfloor.org>
To:	Matthew Garrett <mjg59@...f.ucam.org>
Cc:	linux-kernel@...r.kernel.org, linux-pci@...ey.karlin.mff.cuni.cz,
	gregkh@...e.de
Subject: Re: [RFC] Runtime allocation of PCI resources

Matthew Garrett <mjg59@...f.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@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/