In preparation for using set_memory_uc() instead set_memory_np() for
isolating poison from speculation, teach the memtype code to sanitize
physical addresses vs __PHYSICAL_MASK.

The motivation for using set_memory_uc() for this case is to allow
ongoing access to persistent memory pages via the pmem-driver +
memcpy_mcsafe() until the poison is repaired.

Cc: Thomas Gleixner <t...@linutronix.de>
Cc: Ingo Molnar <mi...@redhat.com>
Cc: "H. Peter Anvin" <h...@zytor.com>
Cc: Tony Luck <tony.l...@intel.com>
Cc: Borislav Petkov <b...@alien8.de>
Cc: <linux-e...@vger.kernel.org>
Cc: <x...@kernel.org>
Signed-off-by: Dan Williams <dan.j.willi...@intel.com>
---
 arch/x86/mm/pat.c |   16 ++++++++++++++++
 1 file changed, 16 insertions(+)

diff --git a/arch/x86/mm/pat.c b/arch/x86/mm/pat.c
index 1555bd7d3449..6788ffa990f8 100644
--- a/arch/x86/mm/pat.c
+++ b/arch/x86/mm/pat.c
@@ -512,6 +512,17 @@ static int free_ram_pages_type(u64 start, u64 end)
        return 0;
 }
 
+static u64 sanitize_phys(u64 address)
+{
+       /*
+        * When changing the memtype for pages containing poison allow
+        * for a "decoy" virtual address (bit 63 clear) passed to
+        * set_memory_X(). __pa() on a "decoy" address results in a
+        * physical address with it 63 set.
+        */
+       return address & __PHYSICAL_MASK;
+}
+
 /*
  * req_type typically has one of the:
  * - _PAGE_CACHE_MODE_WB
@@ -533,6 +544,8 @@ int reserve_memtype(u64 start, u64 end, enum 
page_cache_mode req_type,
        int is_range_ram;
        int err = 0;
 
+       start = sanitize_phys(start);
+       end = sanitize_phys(end);
        BUG_ON(start >= end); /* end is exclusive */
 
        if (!pat_enabled()) {
@@ -609,6 +622,9 @@ int free_memtype(u64 start, u64 end)
        if (!pat_enabled())
                return 0;
 
+       start = sanitize_phys(start);
+       end = sanitize_phys(end);
+
        /* Low ISA region is always mapped WB. No need to track */
        if (x86_platform.is_untracked_pat_range(start, end))
                return 0;

_______________________________________________
Linux-nvdimm mailing list
Linux-nvdimm@lists.01.org
https://lists.01.org/mailman/listinfo/linux-nvdimm

Reply via email to