I am using the latest set (version 6) of SR-IOV patches with 2.6.28-rc4 kernel, and I am running into a problem with the allocation of resources to BARs. Though I am using this code on powerpc, the problem could occur on other platforms too. I am looking for help in correcting my understanding... The adapter that I am using supports 16 VFs. The PF BARs are configured as 64-bit, and request 8MB, 4K, and 256B respectively. The VF BARs are also configured as 64-bit, and request 8MB, 8K, and 8K respectively. Here is the output from the dmesg: pci 0000:01:00.0: reg 10 64bit mmio: [0x000000-0x7fffff] pci 0000:01:00.0: reg 18 64bit mmio: [0x000000-0x000fff] pci 0000:01:00.0: reg 20 64bit mmio: [0x000000-0x0000ff] pci 0000:01:00.0: reg 30 32bit mmio: [0x000000-0x07ffff] pci 0000:01:00.0: reg 194 64bit mmio: [0x000000-0x7fffff] pci 0000:01:00.0: reg 19c 64bit mmio: [0x000000-0x001fff] pci 0000:01:00.0: reg 1a4 64bit mmio: [0x000000-0x001fff] During the resource setup phase, I have noticed that pci_update_resource() gets called with resno 0 (BAR 0), 6 (PCI_ROM_RESOURCE), 2 (BAR 2), 7 (VF BAR 0), 9 (VF BAR 2), 11 (VF BAR 4), and 4 (BAR 4), in that order. resno 0 (BAR 0) gets bus range 0x80000000-0x807fffff allocated to it. resno 6 (PCI_ROM_RESOURCE) gets bus range 0x80800000-0x8087ffff. resno 2 (BAR 2) gets bus range 0x80880000-0x80880fff. So far so good... Now, resno 7 (VF BAR 0) gets bus range 0x80881000-0x88880fff allocated to it. But when 0x8088100c is written to VF BAR 0, the adpater returns 0x8080000c. The adapter seems to expect the region to fall on a 8MB boundary, but the address we assigned falls on a 4K boundary. The question then is, is the adapter behaving correctly when it expects the assigned address to fall on a 8MB boundary? I remember reading somewhere that the addresses should always fall on a boundary that is a multiple of the size requested! If the adapter is correct, then shouldn't the kernel code assign the addresses taking care of their sizes? In this case, if the pci_update_resource() was called for resno 7, 0, 6, 9, 11, 2, 4 (in that order), the problem may not have occurred! I see this same problem for other resno values that also fall on incorrect boundaries... Am I missing something? Any help/suggestion is greatly appreciated... Venu -- To unsubscribe from this list: send the line "unsubscribe linux-pci" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
