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 <j...@ziepe.ca> 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()
How confident are you in the bisection?
Jason
_______________________________________________
Linux-nvdimm mailing list -- linux-nvdimm@lists.01.org
To unsubscribe send an email to linux-nvdimm-le...@lists.01.org
