From: Borislav Petkov <bp@alien8.de>
To: Dan Williams <dan.j.williams@intel.com>
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: Fri, 1 Oct 2021 12:41:47 +0200 [thread overview]
Message-ID: <YVbl6wkUvbk8vsn7@zn.tnic> (raw)
In-Reply-To: <CAPcyv4jV_8JCNSXg9W3ZNDhZEd=z2QyLWPgLUiVN92rp7zWReA@mail.gmail.com>
On Thu, Sep 30, 2021 at 03:44:40PM -0700, Dan Williams wrote:
> 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.
Well, the driver has special knowledge so *actually* it could go and use
the NP marking as "this page has been poisoned" and mark it NC only for
itself, so that it gets the job done. Dunno if that would end up being
too ugly to live and turn into a layering violation or so.
Or we can mark the page NC - that should stop the speculative access for
DRAM and the PMEM driver can do its job. The NC should take care so that
no cachelines are in the cache hierarchy.
> 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.
Yeah, I'm looking for the simplest solution first which satisfies
everyone. Let's keep that one on the bag for now...
:-)
--
Regards/Gruss,
Boris.
https://people.kernel.org/tglx/notes-about-netiquette
next prev parent reply other threads:[~2021-10-01 10:41 UTC|newest]
Thread overview: 48+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-07-07 1:01 [RFT PATCH] x86/pat: Fix set_mce_nospec() for pmem Dan Williams
2021-08-26 19:08 ` Dan Williams
2021-08-27 7:12 ` Jane Chu
2021-09-13 10:29 ` Borislav Petkov
2021-09-14 18:08 ` Dan Williams
2021-09-15 10:41 ` Borislav Petkov
2021-09-16 20:33 ` Dan Williams
2021-09-17 11:30 ` Borislav Petkov
2021-09-21 2:04 ` Dan Williams
2021-09-30 17:19 ` Borislav Petkov
2021-09-30 17:28 ` Luck, Tony
2021-09-30 19:30 ` Borislav Petkov
2021-09-30 19:41 ` Dan Williams
2021-09-30 19:44 ` Luck, Tony
2021-09-30 20:01 ` Borislav Petkov
2021-09-30 20:15 ` Luck, Tony
2021-09-30 20:32 ` Borislav Petkov
2021-09-30 20:39 ` Dan Williams
2021-09-30 20:54 ` Borislav Petkov
2021-09-30 21:05 ` Dan Williams
2021-09-30 21:20 ` Borislav Petkov
2021-09-30 21:41 ` Dan Williams
2021-09-30 22:35 ` Borislav Petkov
2021-09-30 22:44 ` Dan Williams
2021-10-01 10:41 ` Borislav Petkov [this message]
2021-10-01 0:43 ` Jane Chu
2021-10-01 2:02 ` Dan Williams
2021-10-01 10:50 ` Borislav Petkov
2021-10-01 16:52 ` Dan Williams
2021-10-01 18:11 ` Borislav Petkov
2021-10-01 18:29 ` Dan Williams
2021-10-02 10:17 ` Borislav Petkov
2021-11-11 0:06 ` Jane Chu
2021-11-12 0:30 ` Jane Chu
2021-11-12 0:51 ` Dan Williams
2021-11-12 17:57 ` Jane Chu
2021-11-12 19:24 ` Dan Williams
2021-11-12 22:35 ` Jane Chu
2021-11-12 22:50 ` Jane Chu
2021-11-12 23:08 ` Dan Williams
2021-11-13 5:50 ` Jane Chu
2021-11-13 20:47 ` Dan Williams
2021-11-18 19:03 ` Jane Chu
2021-11-25 0:16 ` Dan Williams
2021-11-30 23:00 ` Jane Chu
2021-09-30 18:15 ` Jane Chu
2021-09-30 19:11 ` Dan Williams
2021-09-30 21:23 ` Jane Chu
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=YVbl6wkUvbk8vsn7@zn.tnic \
--to=bp@alien8.de \
--cc=dan.j.williams@intel.com \
--cc=jane.chu@oracle.com \
--cc=mcgrof@suse.com \
--cc=nvdimm@lists.linux.dev \
--cc=tony.luck@intel.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).