All of lore.kernel.org
 help / color / mirror / Atom feed
From: Jason Gunthorpe <jgg@nvidia.com>
To: Daniel Vetter <daniel@ffwll.ch>
Cc: David Airlie <airlied@linux.ie>,
	Bartlomiej Zolnierkiewicz <b.zolnierkie@samsung.com>,
	<dri-devel@lists.freedesktop.org>, <linux-fbdev@vger.kernel.org>,
	Maarten Lankhorst <maarten.lankhorst@linux.intel.com>,
	Maxime Ripard <mripard@kernel.org>,
	Thomas Zimmermann <tzimmermann@suse.de>,
	Tom Lendacky <thomas.lendacky@amd.com>
Subject: Re: [PATCH] drm: remove pgprot_decrypted() before calls to io_remap_pfn_range()
Date: Thu, 5 Nov 2020 15:35:54 -0400	[thread overview]
Message-ID: <20201105193554.GP2620339@nvidia.com> (raw)
In-Reply-To: <20201105191746.GC401619@phenom.ffwll.local>

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

WARNING: multiple messages have this Message-ID (diff)
From: Jason Gunthorpe <jgg@nvidia.com>
To: Daniel Vetter <daniel@ffwll.ch>
Cc: Tom Lendacky <thomas.lendacky@amd.com>,
	linux-fbdev@vger.kernel.org,
	Bartlomiej Zolnierkiewicz <b.zolnierkie@samsung.com>,
	David Airlie <airlied@linux.ie>,
	dri-devel@lists.freedesktop.org,
	Thomas Zimmermann <tzimmermann@suse.de>
Subject: Re: [PATCH] drm: remove pgprot_decrypted() before calls to io_remap_pfn_range()
Date: Thu, 5 Nov 2020 15:35:54 -0400	[thread overview]
Message-ID: <20201105193554.GP2620339@nvidia.com> (raw)
In-Reply-To: <20201105191746.GC401619@phenom.ffwll.local>

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
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

  reply	other threads:[~2020-11-05 19:36 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-11-05 17:00 [PATCH] drm: remove pgprot_decrypted() before calls to io_remap_pfn_range() Jason Gunthorpe
2020-11-05 17:00 ` Jason Gunthorpe
2020-11-05 19:17 ` Daniel Vetter
2020-11-05 19:17   ` Daniel Vetter
2020-11-05 19:35   ` Jason Gunthorpe [this message]
2020-11-05 19:35     ` Jason Gunthorpe
2020-11-10 12:54     ` Daniel Vetter
2020-11-10 12:54       ` Daniel Vetter
2020-11-10 16:19 ` Daniel Vetter
2020-11-10 16:19   ` Daniel Vetter

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=20201105193554.GP2620339@nvidia.com \
    --to=jgg@nvidia.com \
    --cc=airlied@linux.ie \
    --cc=b.zolnierkie@samsung.com \
    --cc=daniel@ffwll.ch \
    --cc=dri-devel@lists.freedesktop.org \
    --cc=linux-fbdev@vger.kernel.org \
    --cc=maarten.lankhorst@linux.intel.com \
    --cc=mripard@kernel.org \
    --cc=thomas.lendacky@amd.com \
    --cc=tzimmermann@suse.de \
    /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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.