On 11/10/20 8:36 AM, Jason Gunthorpe wrote:
On Mon, Nov 09, 2020 at 01:54:42PM -0400, Jason Gunthorpe wrote:
On Mon, Nov 09, 2020 at 09:26:19AM -0800, Dan Williams wrote:
On Mon, Nov 9, 2020 at 6:12 AM Jason Gunthorpe <[email protected]> wrote:
Wow, this is surprising
This has been widely backported already, Dan please check??
I thought pgprot_decrypted was a NOP on most x86 platforms -
sme_me_mask == 0:
#define __sme_set(x) ((x) | sme_me_mask)
#define __sme_clr(x) ((x) & ~sme_me_mask)
??
Confused how this can be causing DAX issues
Does that correctly preserve the "soft" pte bits? Especially
PTE_DEVMAP that DAX uses?
I'll check...
extern u64 sme_me_mask;
#define __pgprot(x) ((pgprot_t) { (x) } )
#define pgprot_val(x) ((x).pgprot)
#define __sme_clr(x) ((x) & ~sme_me_mask)
#define pgprot_decrypted(prot) __pgprot(__sme_clr(pgprot_val(prot)))
static inline int io_remap_pfn_range(struct vm_area_struct *vma,
unsigned long addr, unsigned long pfn,
unsigned long size, pgprot_t prot)
{
return remap_pfn_range(vma, addr, pfn, size, pgprot_decrypted(prot));
}
Not seeing how that could change the pgprot in any harmful way?
Yi, are you using a platform where sme_me_mask != 0 ?
That code looks clearly like it would only trigger on AMD SME systems,
is that what you are using?
Can't be, the system is too old:
[ 398.455914] Hardware name: HP ProLiant DL380 Gen9/ProLiant DL380 Gen9,
BIOS P89 10/05/2016
I'm at a total loss how this change could even do anything on a
non-AMD system, let alone how this intersects in any way with DEVDAX,
which I could not find being used with io_remap_pfn_range()
I will double confirm it.
How confident are you in the bisection?
Jason
_______________________________________________
Linux-nvdimm mailing list -- [email protected]
To unsubscribe send an email to [email protected]
