Re: [RFT PATCH] x86/pat: Fix set_mce_nospec() for pmem

From: Dan Williams <dan.j.williams@intel.com>
To: Borislav Petkov <bp@alien8.de>
Cc: "Luck, Tony" <tony.luck@intel.com>,
	Linux NVDIMM <nvdimm@lists.linux.dev>,
	 Jane Chu <jane.chu@oracle.com>,
	Luis Chamberlain <mcgrof@suse.com>
Subject: Re: [RFT PATCH] x86/pat: Fix set_mce_nospec() for pmem
Date: Thu, 30 Sep 2021 15:44:40 -0700	[thread overview]
Message-ID: <CAPcyv4jV_8JCNSXg9W3ZNDhZEd=z2QyLWPgLUiVN92rp7zWReA@mail.gmail.com> (raw)
In-Reply-To: <YVY7wY/mhMiRLATk@zn.tnic>

On Thu, Sep 30, 2021 at 3:36 PM Borislav Petkov <bp@alien8.de> 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.