On Wed, Oct 06, 2010 at 04:57:06PM -0700, H. Peter Anvin wrote: > On 10/06/2010 04:17 PM, Bjorn Helgaas wrote: > > On Wed, Oct 06, 2010 at 03:45:09PM -0700, H. Peter Anvin wrote: > >> On 10/06/2010 09:06 AM, Bjorn Helgaas wrote: > >>> > >>> On some chipsets, e.g., the AMD RS780, the MMCONFIG base address is set via > >>> a host bridge "BAR." But this isn't really a BAR in the sense of a decoder > >>> for addresses on a PCI bus. The host bridge converts host accesses to the > >>> MMCONFIG region into PCI configuration accesses, so the MMCONFIG addresses > >>> never appear on the PCI bus. > >>> > >>> In addition, this "BAR" is often larger than the MMCONFIG region proper, so > >>> it can overlap other real PCI devices, which causes resource allocation > >>> conflicts. PCI cannot move this BAR because the MMCONFIG code has already > >>> discovered it, so we might as well ignore it. > >>> > >>> Here's the typical signature, showing the spurious "no compatible bridge > >>> window" and "PNP resource overlaps PCI BAR" warnings: > >>> > >>> PCI: MMCONFIG for domain 0000 [bus 00-ff] at [mem 0xe0000000-0xefffffff] (base 0xe0000000) > >>> pci_root PNP0A03:00: host bridge window [mem 0x7ff00000-0xfebfffff] > >>> pci 0000:00:00.0: BAR 3: [mem 0xe0000000-0xffffffff 64bit] > >>> pci 0000:00:00.0: no compatible bridge window for [mem 0xe0000000-0xffffffff 64bit] > >>> pnp 00:02: disabling [mem 0x00000000-0x00000fff window] because it overlaps 0000:00:00.0 BAR 3 [mem 0x00000000-0x1fffffff 64bit] > >>> > >>> Note that when we didn't find a host bridge window for the BAR, we cleared > >>> the resource starting address (but not the BAR register itself), leading to > >>> the pnp 00:02 conflict. > >> > >> This sounds like yet another case of an early-discovered resource which > >> needs to be treated as fixed. Any reason to not do the same thing as > >> for HPET and just mark them as fixed? > > > > It is similar in that we can't move it because the MMCONFIG code has > > already discovered it. > > > > But it's different in that the BAR reports a range that is much larger than > > the actual MMCONFIG range, and the excess conflicts with many other PCI and > > ACPI devices. The other devices work fine, so clearly the host bridge is > > forwarding the 0xf0000000-0xfebfffff range to PCI, not claiming it for > > itself. > > > > I think marking it fixed would just cause conflicts with the devices in > > that range rather than in the 0x00000000-0x1fffffff range. > > > > The AMD doc mentions an enable bit (HIDE_MMCFG_BAR), and I suppose we could > > set that and make the whole thing go away. But I sort of hate to add > > chipset-specific information unless we have to. > > > > Hm, well, the actual bug here seems to be that the BAR doesn't size > properly (it sizes as 512 MiB when it is actually only 256 MiB large, as > that is the total size of the MMCONFIG window.) As such it would seem > that a chipset-specific quirk would be appropriate. Either that or > forcing MMCONFIG BARs to 256 MiB if this crops up on other chipsets. Both definitely good possibilities. I guess I'm still hopeful for a generic fix because I'm skeptical that Windows would have a chipset-specific quirk for this. If Windows had such a quirk, I think it would mean that the affected systems would have had to wait for a Windows release to work properly, and I just can't imagine a vendor delaying shipment rather than making a BIOS fix. (Though I guess I don't know for sure that Windows supports MMCONFIG on these systems. I suppose it's possible that they just turn off MMCONFIG.) My other hesitation is that if we correct the BAR size to 256 MiB, we still end up with that resource being reported both as a PCI BAR and in the _CRS for an ACPI motherboard device, and that doesn't feel quite right to me. >From that perspective, I would prefer the chipset-specific HIDE_MMCFG_BAR idea. This patch doesn't actually make a functional difference, so maybe we should just wait and hope we can learn more about it. 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
