On Tue, Jan 10, 2023 at 5:46 AM Bjorn Helgaas <helgaas@xxxxxxxxxx> wrote: > > Can we make the subject line any more specific about what this patch > does? Apparently this is really about avoiding accidental enablement > of the window because the base & limit can't be updated atomically? Sure, I will rephrase the subject. > #define PCI_IO_BASE 0x1c > #define PCI_PREF_LIMIT_UPPER32 0x2c > #define PCI_ROM_ADDRESS1 0x38 > > memset_io(base + PCI_IO_BASE, 0, PCI_ROM_ADDRESS1 - PCI_IO_BASE); > > The memset does clear PCI_PREF_LIMIT_UPPER32 already, but I think > you're saying that PCI_PREF_MEMORY_BASE, PCI_PREF_MEMORY_LIMIT, and > PCI_PREF_BASE_UPPER32 are cleared first, so there is a time when the > prefetchable base is zero and the limit is non-zero, so the window is > enabled. Yes, your understanding is correct. > I would expect that to be a transient thing that you wouldn't be > likely to trip over, but you seem to see it consistently. > > > This behavior causes that the content of PCI configuration space of VMD > > root ports is 0xff after invoking memset_io() in vmd_domain_reset(): > > Well, it doesn't actually change the content of config space, does it? > I assume these config accesses get routed the wrong place because the > window is enabled, and some PCI error like Unsupported Request is > getting turned into ~0? Yes, I think so. I'll rephrase the commit message accordingly. -- Adrian
