On Thu, Jan 05, 2023 at 01:43:20PM -0800, Dan Williams wrote: > Bjorn Helgaas wrote: > > On Thu, Jan 05, 2023 at 01:20:36PM -0800, Dan Williams wrote: > > > Bjorn Helgaas wrote: > > > > On Thu, Jan 05, 2023 at 11:44:28AM -0800, Dan Williams wrote: > > > > > Would it be enough to add this clarification in "EFI 2.9 Table 7-6 > > > > > Memory Type Usage after ExitBootServices()"? > > > > > > > > > > s/This memory is not used by the OS./This memory is not used by the OS, > > > > > unless ACPI declares it for another purpose./ > > > > > > > > I guess the idea is that MCFG is a form of "ACPI declaring it"? I > > > > don't have an explicit citation for it, but I infer at [1] that ACPI > > > > static tables are second-class citizens and not intended as a way of > > > > reserving address space because that would lead to problems booting > > > > old OSes on firmware that provides new tables unknown to the OS. > > > > > > Ah, true, certainly for new stuff, but what about MCFG specifically? > > > What harm is there an assuming that MMCONFIG intersecting with > > > EfiMemoryMappedIO shall be treated as reserved for MMCONFIG usage. > > > > Probably none, and I think that's what we'll have to do. Ugh. > > Another random special-case rule. > > > > > > [1] https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/Documentation/PCI/acpi-info.rst?id=v6.1#n32 > > I am still holding out that a BIOS developer can either say "whoops, > populating MMCONFIG in _CRS was overlooked", or point out "if you take > the derivative of the PCI spec, multiply it be the inverse of the EFI > spec and then take the cross-product with the ACPI spec then the memory > type comes out as implicitly reserved". Hahaha :) Yep, but even if they change it, apparently there are lots of machines in the field that won't get updated, so we're stuck working around it. Or, I guess the best-case scenario would be that it's not actually a firmware bug, and there's some clean fix we can make to Linux. But I'm not holding my breath.
