On Sat, 2011-10-08 at 15:53 +0800, Ram Pai wrote: > On Sat, Oct 08, 2011 at 08:59:28AM +0200, Benjamin Herrenschmidt wrote: > > On Sat, 2011-10-08 at 07:25 +0800, Ram Pai wrote: > > > On x86, the code anyway works the way you mention. It allocates space > > > to the VF BARs, only if available and is non-conflicting. If it is > > > unable to do so, sriov_init() and its friends don't do much. > > > > They already do too much (ie changing num VF, changing page size), > > that's enough to break some drivers. > > num VFs are set so that VF BARs can be allocated a resource-size > that is a multiple of num VFs. But you can -remember- it without actually affecting config space at that point no ? Or do you need to whack it to know the size ? In which case, just like we set/reset BARs when sizing them, it might be worth resetting numVF in config space after the sizing until we actually need those VFs. > page size is set so that the VF BARs can be aligned on page size > boundaries. Yes except that page size affects a lot more than the VF BARs and has all sort of nasty issues when changed. Again, you can set it to calculate things and reset it until needed. For example, it will cause internal data structure, DMA objects, etc... to change size. it might break drivers (or even firmware in some cases). The VF stride will actually be some -multiple- of the configured page size, in some cases enormous. We talked about this internally with the pHyp IO architects and we probably want to come up with a smarter algorithm that involves a loop of changing the page size, checking the stride, etc... to find the "best" page size for a given system. Also with EEH, we will need to ensure on some PHBs that the stride between VFs is at least 2M, thus playing with page size to achieve that. Having the generic code whack it like it does will prevent that from working. > Now none of them is required and can be postponed to a later time, > if we know the BIOS/UEFI has done a excellent job allocating > resources. Unfortunately that is not the case sometimes :( No surprise here :-) Cheers, Ben. -- 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
