On Thu, Dec 29, 2011 at 06:00:04PM +1300, Alexey Korolev wrote: > On 29/12/11 15:56, Kevin O'Connor wrote: > >On Wed, Dec 28, 2011 at 06:26:05PM +1300, Alexey Korolev wrote: > >>--- a/src/pciinit.c > >>+++ b/src/pciinit.c > >>@@ -22,6 +22,7 @@ enum pci_region_type { > >> PCI_REGION_TYPE_IO, > >> PCI_REGION_TYPE_MEM, > >> PCI_REGION_TYPE_PREFMEM, > >>+ PCI_REGION_TYPE_PREFMEM_64, > >> PCI_REGION_TYPE_COUNT, > >> }; > >This doesn't seem right. A 64bit bar is not a new category - it's > >just a way of representing larger values within the existing > >categories. Tracking of 64bit prefmem sections separately from > >regular prefmem sections doesn't make sense, because both need to be > >allocated from the same pool when behind a bridge. > It's a way to account all memory sections on the root bus, as > on the root bus we can have all 4 regions. > I don't like this part as well, it causes confusions.
The root bus can have five regions - 64bit non-prefmem is also possible. Given that the allocation for devices on the root bus is distinct from devices behind bridges, I think one could separate out the root bus assignment pass into its own code. Indeed, much of the root bus allocation is already separate. > It makes sense to figure out how shall we account all memory > sections on the root bus. > Will it be separated structures for root bus and secondary buses? Do > you have another idea? As an idea - keep the current three buckets (io, mem, prefmem) in struct pci_bus, but expand them to track 64bit sizes. Add a new flag to each bucket to track if every device on the given bus is 64bit capable for that resource. When assigning the resources for a bridge, only use 64bit prefmem if all prefmem bars behind that bridge are 64bit capable. -Kevin