On Thu, Sep 30, 2021 at 3:36 PM Borislav Petkov <[email protected]> wrote: > > On Thu, Sep 30, 2021 at 02:41:52PM -0700, Dan Williams wrote: > > I fail to see the point of that extra plumbing when MSi_MISC > > indicating "whole_page", or not is sufficient. What am I missing? > > I think you're looking at it from the wrong side... (or it is too late > here, but we'll see). Forget how a memory type can be mapped but think > about how the recovery action looks like. > > - DRAM: when a DRAM page is poisoned, it is only poisoned as a whole > page by memory_failure(). whole_page is always true here, no matter what > the hardware says because we don't and cannot do any sub-page recovery > actions. So it doesn't matter how we map it, UC, NP... I suggested NP > because the page is practically not present if you want to access it > because mm won't allow it... > > - PMEM: reportedly, we can do sub-page recovery here so PMEM should be > mapped in the way it is better for the recovery action to work. > > In both cases, the recovery action should control how the memory type is > mapped. > > Now, you say we cannot know the memory type when the error gets > reported. > > And I say: for simplicity's sake, we simply go and work with whole > pages. Always. That is the case anyway for DRAM. > > For PMEM, AFAIU, it doesn't matter whether it is a whole page or not - > the PMEM driver knows how to do those sub-pages accesses. > > IOW, set_mce_nospec() should simply do: > > rc = set_memory_np(decoy_addr, 1); > > and that's it.
The driver uses the direct-map to do the access. It uses the direct-map because it has also arranged for pfn_to_page() to work for PMEM pages. So if PMEM is in the direct-map is marked NP then the sub-page accesses will fault. Now, the driver could set up and tear down page tables for the pfn whenever it is asked to do I/O over a potentially poisoned pfn. Is that what you are suggesting? It seems like a significant amount of overhead, but it would at least kick this question out of the purview of the MCE code.
