On Friday, October 15, 2010 02:06:35 pm H. Peter Anvin wrote: > On 10/15/2010 01:04 PM, Jesse Barnes wrote: > > > > So we have a couple of bugs here? > > - device reports incorrect range (according to Yinghai this is a > > hardware bug) > > - BIOS doesn't set the hidden bit to make this BAR invisible > > > > So rather than applying the quirk which might hide future problems it > > seems we should fix the range reporting with a quirk and possibly set > > the hidden bit on chipsets that support it (though I'd be happier if I > > knew the failure to set it really was a BIOS bug; I guess we won't know > > unless we figure out how Windows behaves on these platforms). > > > > There are a couple of problems: > > a) Linux doesn't handle it correctly when MMCONFIG is a BAR. > This is legitimate and in fact explicitly stated as a valid > configuration in the PCIe spec; the BAR, of course, has to be > configured by BIOS using ports CF8/CFC. My patch and changelog suggested that Linux doesn't handle MMCONFIG BARs correctly. But I don't think that's really true; I think Linux would handle MMCONFIG BARs just fine *IF* they were sized correctly (so they don't conflict with other devices) and described correctly (so they fall within the host bridge windows). In the case of bug 19252, I think the BAR size is wrong and as a consequence, it doesn't fit within the bridge window. [BTW, I'd like to read up on the actual PCIe language about this, but I haven't found it yet. Can you point me to the section?] > b) The BAR is the wrong size (unless it is expected to configure two > different domains, or something.) Yep. The BAR could configure two domains, although the second one couldn't have a full 256 buses. But I think it's more likely that the size is just wrong. > c) Given (b), the BIOS should probably have hidden the BAR as a > workaround. I agree again. And maybe the best fix is for Linux to hide the BAR as we think the BIOS should have. But I still hesitate because I can't imagine Microsoft accepting such a chipset-specific quirk, when all that would have been required was a simple and fairly obvious BIOS fix. I think it's more likely that Windows would read the MMCONFIG BAR, notice that it's not contained in the host bridge windows, try to move it inside, fail (because the window's not large enough), leave the MMCONFIG BAR where it was, read other device BARs, notice that they conflict with the MMCONFIG BAR, try to move them, fail (because in this case there's no space below 0xe0000000 available), and finally just leave these other device BARs where they were and try to use them despite the apparent conflict. And of course, this all assumes Windows does resource management the same eager way Linux does, but I don't know whether that's true. It might make sense to only read device IDs during first-pass enumeration, so we know which drivers to load, and read the BARs lazily, only when we actually bind a driver to the device. Bjorn -- 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
