On Thu, 2020-04-16 at 18:16 +0200, David Hildenbrand wrote: > > > > > > Doing that papers over something that is clearly a FW issue and makes > > > it "my performance is suboptimal" deal with it OS problem. Really, is > > > this something we have to care about. Your changelog talks about a Qemu > > > misconfiguration which is trivial to fix. Has this ever been observed > > > with a real HW? > > > > > Well - more of a qemu bug I think - I can share the details, but it just > > looked like it was producing a bogus SRAT. I think it is plausible that > > such a firmware bug can happen out in the wild. The NFIT tables would > > just need to reference a 'proximity domain' that the SRAT hasn't > > previously described, and hotplug will happily go add memory from the > > NFIT and the backing node related data structures would be missing. > > > > I'm not too opposed to erroring out, so long as we are ok with the fact > > that we will leave some memory stranded until there's a firmware fix. > > So let's reject it and print a warning, so we know it's a thing. If this > actually shows up often in real live, we have good evidence that we > should tolerate buggy firmwares instead of warning/rejecting. > > (rejecting from inside add_memory() still makes sense IMHO) > Sounds good, I'll send a v4.
