Runtime allocation of PCI resources
RFC 1/1 Runtime allocation of PCI resources
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.
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?
drivers/pci/probe.c +1 -1
@@ -126,7 +126,7 @@ static inline unsigned int pci_calc_resource_flags(unsigned int flags)/* * Find the extent of a PCI decode.. */ -static u32 pci_size (u32 base,u32 maxbase,u32 mask) +u32 pci_size (u32 base,u32 maxbase,u32 mask) {u32 size = mask & maxbase;/* Find the significant bits */ if (!size)
drivers/pci/setup-res.c +45 -0
51 lines not on this page · raw message
include/linux/pci.h +2 -0
@@ -549,6 +549,7 @@ void pci_intx(struct pci_dev *dev, int enable);void pci_msi_off (struct pci_dev *dev);int pci_set_dma_mask (struct pci_dev *dev,u64 mask);int pci_set_consistent_dma_mask (struct pci_dev *dev,u64 mask); +int pci_allocate_resource (struct pci_dev *dev,int resno);void pci_update_resource (struct pci_dev *dev,struct resource *res,int resno);int __must_check pci_assign_resource (struct pci_dev *dev,int i);int __must_check pci_assign_resource_fixed (struct pci_dev *dev,int i);
@@ -608,6 +609,7 @@ void pci_remove_behind_bridge(struct pci_dev *);struct pci_driver *pci_dev_driver (const struct pci_dev *);const struct pci_device_id *pci_match_device (struct pci_driver *drv,struct pci_dev *dev);const struct pci_device_id *pci_match_id (const struct pci_device_id *ids,struct pci_dev *dev); +u32 pci_size (u32 base,u32 maxbase,u32 mask);int pci_scan_bridge (struct pci_bus *bus,struct pci_dev * dev,int max,int pass); void pci_walk_bus(struct pci_bus *top, void (*cb)(struct pci_dev *, void *),
Signature · 1 line
Matthew Garrett | [email protected]
Quoted 5 lines · Matthew Garrett
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.
Quoted 11 lines
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
Quoted 8 lines · Andi Kleen
Quoted 5 lines · Matthew Garrett
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.
Quoted 4 lines
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.
AHCI is generally disabled because it makes Windows insanely difficult to install. I'm not aware of any hardware issues in this case.
Quoted 7 lines
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.
Hm. Yes, that would be a problem (sigh BIOS authors).
Signature · 1 line
Matthew Garrett | [email protected]
Quoted 8 lines · Andi Kleen
Quoted 5 lines · Matthew Garrett
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.
Quoted 7 lines
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.
Esp for AMD system with several Hypertranport chain. try to allocate pci resource in kernel also need some region adjust in NB configuration space.
So leave some work to ACPI DSDT AML code at least
YH