| Message ID | 0-v1-2e6a0db57868+166-drm_sme_clean_jgg@nvidia.com |
|---|---|
| State | New |
| Headers | show |
| Series | drm: remove pgprot_decrypted() before calls to io_remap_pfn_range() | expand |
On Thu, Nov 05, 2020 at 01:00:19PM -0400, Jason Gunthorpe wrote: > commit f8f6ae5d077a ("mm: always have io_remap_pfn_range() set > pgprot_decrypted()") moves the pgprot_decrypted() into > io_remap_pfn_range(). Delete any, now confusing, open coded calls that > directly precede io_remap_pfn_range(): > > - drm_io_prot() is only in drm_mmap_locked() to call io_remap_pfn_range() > > - fb_mmap() immediately calls vm_iomap_memory() which is a convenience > wrapper for io_remap_pfn_range() > > Signed-off-by: Jason Gunthorpe <jgg@nvidia.com> > --- > drivers/gpu/drm/drm_vm.c | 3 --- > drivers/video/fbdev/core/fbmem.c | 5 ----- > 2 files changed, 8 deletions(-) > > rc3 will have the dependent patch, this should not be merged to DRM until it > has the rc3 commits. > > There are three other pgprot_decrypted() calls in DRM, I could not figure out > what was what there, but other than very special cases I would expect code to > use io_remap_pfn_range() instead. There's 4 now, I think linux-next added one. It's another io_remap_pfn Of the three you mentioned we have: - ttm and i915 use vm_insert_pfn (and ttm also can do also do pud_mkhuge entries) - drm_gem is for all other drivers, some also use vm_insert_pfn, the others I think use dma_mmap_* and friends, which I think underneath boild down to io_remap_pfn. Or at least should be taking care of this already. I'll try and remember to merge this after -rc3. Yell if it's not in by -rc4 please. -Daniel > > diff --git a/drivers/gpu/drm/drm_vm.c b/drivers/gpu/drm/drm_vm.c > index 1a636963378947..6d5a03b3223800 100644 > --- a/drivers/gpu/drm/drm_vm.c > +++ b/drivers/gpu/drm/drm_vm.c > @@ -70,9 +70,6 @@ static pgprot_t drm_io_prot(struct drm_local_map *map, > { > pgprot_t tmp = vm_get_page_prot(vma->vm_flags); > > - /* We don't want graphics memory to be mapped encrypted */ > - tmp = pgprot_decrypted(tmp); > - > #if defined(__i386__) || defined(__x86_64__) || defined(__powerpc__) || \ > defined(__mips__) > if (map->type == _DRM_REGISTERS && !(map->flags & _DRM_WRITE_COMBINING)) > diff --git a/drivers/video/fbdev/core/fbmem.c b/drivers/video/fbdev/core/fbmem.c > index 8268bbee8cae11..63a27a67a05cfa 100644 > --- a/drivers/video/fbdev/core/fbmem.c > +++ b/drivers/video/fbdev/core/fbmem.c > @@ -1386,11 +1386,6 @@ fb_mmap(struct file *file, struct vm_area_struct * vma) > mutex_unlock(&info->mm_lock); > > vma->vm_page_prot = vm_get_page_prot(vma->vm_flags); > - /* > - * The framebuffer needs to be accessed decrypted, be sure > - * SME protection is removed > - */ > - vma->vm_page_prot = pgprot_decrypted(vma->vm_page_prot); > fb_pgprotect(file, vma, start); > > return vm_iomap_memory(vma, start, len); > -- > 2.29.2 > -- Daniel Vetter Software Engineer, Intel Corporation http://blog.ffwll.ch
On Thu, Nov 05, 2020 at 08:17:46PM +0100, Daniel Vetter wrote: > On Thu, Nov 05, 2020 at 01:00:19PM -0400, Jason Gunthorpe wrote: > > commit f8f6ae5d077a ("mm: always have io_remap_pfn_range() set > > pgprot_decrypted()") moves the pgprot_decrypted() into > > io_remap_pfn_range(). Delete any, now confusing, open coded calls that > > directly precede io_remap_pfn_range(): > > > > - drm_io_prot() is only in drm_mmap_locked() to call io_remap_pfn_range() > > > > - fb_mmap() immediately calls vm_iomap_memory() which is a convenience > > wrapper for io_remap_pfn_range() > > > > Signed-off-by: Jason Gunthorpe <jgg@nvidia.com> > > drivers/gpu/drm/drm_vm.c | 3 --- > > drivers/video/fbdev/core/fbmem.c | 5 ----- > > 2 files changed, 8 deletions(-) > > > > rc3 will have the dependent patch, this should not be merged to DRM until it > > has the rc3 commits. > > > > There are three other pgprot_decrypted() calls in DRM, I could not figure out > > what was what there, but other than very special cases I would expect code to > > use io_remap_pfn_range() instead. > > There's 4 now, I think linux-next added one. It's another io_remap_pfn > > Of the three you mentioned we have: > - ttm and i915 use vm_insert_pfn (and ttm also can do also do pud_mkhuge > entries) You can't insert IO memory with vmf_insert_pfn_pmd_prot() (it doesn't set the special flag) so why does it need decrypted? Jason
On Thu, Nov 05, 2020 at 03:35:54PM -0400, Jason Gunthorpe wrote: > On Thu, Nov 05, 2020 at 08:17:46PM +0100, Daniel Vetter wrote: > > On Thu, Nov 05, 2020 at 01:00:19PM -0400, Jason Gunthorpe wrote: > > > commit f8f6ae5d077a ("mm: always have io_remap_pfn_range() set > > > pgprot_decrypted()") moves the pgprot_decrypted() into > > > io_remap_pfn_range(). Delete any, now confusing, open coded calls that > > > directly precede io_remap_pfn_range(): > > > > > > - drm_io_prot() is only in drm_mmap_locked() to call io_remap_pfn_range() > > > > > > - fb_mmap() immediately calls vm_iomap_memory() which is a convenience > > > wrapper for io_remap_pfn_range() > > > > > > Signed-off-by: Jason Gunthorpe <jgg@nvidia.com> > > > drivers/gpu/drm/drm_vm.c | 3 --- > > > drivers/video/fbdev/core/fbmem.c | 5 ----- > > > 2 files changed, 8 deletions(-) > > > > > > rc3 will have the dependent patch, this should not be merged to DRM until it > > > has the rc3 commits. > > > > > > There are three other pgprot_decrypted() calls in DRM, I could not figure out > > > what was what there, but other than very special cases I would expect code to > > > use io_remap_pfn_range() instead. > > > > There's 4 now, I think linux-next added one. It's another io_remap_pfn > > > > Of the three you mentioned we have: > > - ttm and i915 use vm_insert_pfn (and ttm also can do also do pud_mkhuge > > entries) > > You can't insert IO memory with vmf_insert_pfn_pmd_prot() (it > doesn't set the special flag) so why does it need decrypted? Well, see the other thread, we do ... :-/ -Daniel -- Daniel Vetter Software Engineer, Intel Corporation http://blog.ffwll.ch
On Thu, Nov 05, 2020 at 01:00:19PM -0400, Jason Gunthorpe wrote: > commit f8f6ae5d077a ("mm: always have io_remap_pfn_range() set > pgprot_decrypted()") moves the pgprot_decrypted() into > io_remap_pfn_range(). Delete any, now confusing, open coded calls that > directly precede io_remap_pfn_range(): > > - drm_io_prot() is only in drm_mmap_locked() to call io_remap_pfn_range() > > - fb_mmap() immediately calls vm_iomap_memory() which is a convenience > wrapper for io_remap_pfn_range() > > Signed-off-by: Jason Gunthorpe <jgg@nvidia.com> Pushed to drm-misc-next now, thanks for your patch. -Daniel > --- > drivers/gpu/drm/drm_vm.c | 3 --- > drivers/video/fbdev/core/fbmem.c | 5 ----- > 2 files changed, 8 deletions(-) > > rc3 will have the dependent patch, this should not be merged to DRM until it > has the rc3 commits. > > There are three other pgprot_decrypted() calls in DRM, I could not figure out > what was what there, but other than very special cases I would expect code to > use io_remap_pfn_range() instead. > > diff --git a/drivers/gpu/drm/drm_vm.c b/drivers/gpu/drm/drm_vm.c > index 1a636963378947..6d5a03b3223800 100644 > --- a/drivers/gpu/drm/drm_vm.c > +++ b/drivers/gpu/drm/drm_vm.c > @@ -70,9 +70,6 @@ static pgprot_t drm_io_prot(struct drm_local_map *map, > { > pgprot_t tmp = vm_get_page_prot(vma->vm_flags); > > - /* We don't want graphics memory to be mapped encrypted */ > - tmp = pgprot_decrypted(tmp); > - > #if defined(__i386__) || defined(__x86_64__) || defined(__powerpc__) || \ > defined(__mips__) > if (map->type == _DRM_REGISTERS && !(map->flags & _DRM_WRITE_COMBINING)) > diff --git a/drivers/video/fbdev/core/fbmem.c b/drivers/video/fbdev/core/fbmem.c > index 8268bbee8cae11..63a27a67a05cfa 100644 > --- a/drivers/video/fbdev/core/fbmem.c > +++ b/drivers/video/fbdev/core/fbmem.c > @@ -1386,11 +1386,6 @@ fb_mmap(struct file *file, struct vm_area_struct * vma) > mutex_unlock(&info->mm_lock); > > vma->vm_page_prot = vm_get_page_prot(vma->vm_flags); > - /* > - * The framebuffer needs to be accessed decrypted, be sure > - * SME protection is removed > - */ > - vma->vm_page_prot = pgprot_decrypted(vma->vm_page_prot); > fb_pgprotect(file, vma, start); > > return vm_iomap_memory(vma, start, len); > -- > 2.29.2 > -- Daniel Vetter Software Engineer, Intel Corporation http://blog.ffwll.ch
diff --git a/drivers/gpu/drm/drm_vm.c b/drivers/gpu/drm/drm_vm.c index 1a636963378947..6d5a03b3223800 100644 --- a/drivers/gpu/drm/drm_vm.c +++ b/drivers/gpu/drm/drm_vm.c @@ -70,9 +70,6 @@ static pgprot_t drm_io_prot(struct drm_local_map *map, { pgprot_t tmp = vm_get_page_prot(vma->vm_flags); - /* We don't want graphics memory to be mapped encrypted */ - tmp = pgprot_decrypted(tmp); - #if defined(__i386__) || defined(__x86_64__) || defined(__powerpc__) || \ defined(__mips__) if (map->type == _DRM_REGISTERS && !(map->flags & _DRM_WRITE_COMBINING)) diff --git a/drivers/video/fbdev/core/fbmem.c b/drivers/video/fbdev/core/fbmem.c index 8268bbee8cae11..63a27a67a05cfa 100644 --- a/drivers/video/fbdev/core/fbmem.c +++ b/drivers/video/fbdev/core/fbmem.c @@ -1386,11 +1386,6 @@ fb_mmap(struct file *file, struct vm_area_struct * vma) mutex_unlock(&info->mm_lock); vma->vm_page_prot = vm_get_page_prot(vma->vm_flags); - /* - * The framebuffer needs to be accessed decrypted, be sure - * SME protection is removed - */ - vma->vm_page_prot = pgprot_decrypted(vma->vm_page_prot); fb_pgprotect(file, vma, start); return vm_iomap_memory(vma, start, len);
commit f8f6ae5d077a ("mm: always have io_remap_pfn_range() set pgprot_decrypted()") moves the pgprot_decrypted() into io_remap_pfn_range(). Delete any, now confusing, open coded calls that directly precede io_remap_pfn_range(): - drm_io_prot() is only in drm_mmap_locked() to call io_remap_pfn_range() - fb_mmap() immediately calls vm_iomap_memory() which is a convenience wrapper for io_remap_pfn_range() Signed-off-by: Jason Gunthorpe <jgg@nvidia.com> --- drivers/gpu/drm/drm_vm.c | 3 --- drivers/video/fbdev/core/fbmem.c | 5 ----- 2 files changed, 8 deletions(-) rc3 will have the dependent patch, this should not be merged to DRM until it has the rc3 commits. There are three other pgprot_decrypted() calls in DRM, I could not figure out what was what there, but other than very special cases I would expect code to use io_remap_pfn_range() instead.