From: Jason Gunthorpe <jgg@ziepe.ca>
To: Ralph Campbell <rcampbell@nvidia.com>
Cc: amd-gfx@lists.freedesktop.org, nouveau@lists.freedesktop.org,
dri-devel@lists.freedesktop.org, kvm-ppc@vger.kernel.org,
"Christoph Hellwig" <hch@lst.de>,
linux-mm@kvack.org, "Jerome Glisse" <jglisse@redhat.com>,
"Ben Skeggs" <bskeggs@redhat.com>,
"Dan Williams" <dan.j.williams@intel.com>,
"Bharata B Rao" <bharata@linux.ibm.com>,
"Christian König" <christian.koenig@amd.com>
Subject: Re: [PATCH 3/4] mm: simplify device private page handling in hmm_range_fault
Date: Tue, 17 Mar 2020 09:15:36 -0300 [thread overview]
Message-ID: <20200317121536.GQ20941@ziepe.ca> (raw)
In-Reply-To: <7256f88d-809e-4aba-3c46-a223bd8cc521@nvidia.com>
On Mon, Mar 16, 2020 at 03:49:51PM -0700, Ralph Campbell wrote:
>
> On 3/16/20 12:32 PM, Christoph Hellwig wrote:
> > Remove the code to fault device private pages back into system memory
> > that has never been used by any driver. Also replace the usage of the
> > HMM_PFN_DEVICE_PRIVATE flag in the pfns array with a simple
> > is_device_private_page check in nouveau.
> >
> > Signed-off-by: Christoph Hellwig <hch@lst.de>
>
> Getting rid of HMM_PFN_DEVICE_PRIVATE seems reasonable to me since a driver can
> look at the struct page but what if a driver needs to fault in a page from
> another device's private memory? Should it call handle_mm_fault()?
Isn't that what this series basically does?
The dev_private_owner is set to the type of pgmap the device knows how
to handle, and everything else is automatically faulted for the
device.
If the device does not know how to handle device_private then it sets
dev_private_owner to NULL and it never gets device_private pfns.
Since the device_private pfn cannot be dma mapped, drivers must have
explicit support for them.
Jason
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
next prev parent reply other threads:[~2020-03-17 14:17 UTC|newest]
Thread overview: 22+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <20200316193216.920734-1-hch@lst.de>
[not found] ` <20200316193216.920734-2-hch@lst.de>
2020-03-16 20:55 ` [PATCH 1/4] memremap: add an owner field to struct dev_pagemap Ralph Campbell
[not found] ` <20200316193216.920734-3-hch@lst.de>
2020-03-16 21:43 ` [PATCH 2/4] mm: handle multiple owners of device private pages in migrate_vma Ralph Campbell
[not found] ` <20200316193216.920734-4-hch@lst.de>
2020-03-16 19:59 ` [PATCH 3/4] mm: simplify device private page handling in hmm_range_fault Jason Gunthorpe
2020-03-16 22:49 ` Ralph Campbell
2020-03-17 12:15 ` Jason Gunthorpe [this message]
[not found] ` <20200317122445.GA11662@lst.de>
[not found] ` <20200317122813.GA11866@lst.de>
2020-03-17 12:47 ` Jason Gunthorpe
[not found] ` <20200317125955.GA12847@lst.de>
2020-03-17 17:32 ` Jason Gunthorpe
2020-03-17 23:14 ` Ralph Campbell
2020-03-19 18:17 ` Jason Gunthorpe
2020-03-19 22:56 ` Ralph Campbell
2020-03-20 0:03 ` Jason Gunthorpe
2020-03-20 0:14 ` Jason Gunthorpe
2020-03-20 1:33 ` Ralph Campbell
2020-03-20 12:58 ` Jason Gunthorpe
[not found] ` <20200317073454.GA5843@lst.de>
2020-03-17 22:43 ` Ralph Campbell
2020-03-19 0:28 ` ensure device private pages have an owner v2 Jason Gunthorpe
[not found] ` <20200319071633.GA32522@lst.de>
2020-03-19 11:50 ` Jason Gunthorpe
2020-03-19 18:50 ` Jason Gunthorpe
[not found] ` <20200316193216.920734-5-hch@lst.de>
2020-03-16 19:49 ` [PATCH 4/4] mm: check the device private page owner in hmm_range_fault Jason Gunthorpe
2020-03-16 23:11 ` Ralph Campbell
2020-03-20 13:41 ` Jason Gunthorpe
[not found] ` <20200321082236.GB28613@lst.de>
2020-03-21 12:38 ` Jason Gunthorpe
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=20200317121536.GQ20941@ziepe.ca \
--to=jgg@ziepe.ca \
--cc=amd-gfx@lists.freedesktop.org \
--cc=bharata@linux.ibm.com \
--cc=bskeggs@redhat.com \
--cc=christian.koenig@amd.com \
--cc=dan.j.williams@intel.com \
--cc=dri-devel@lists.freedesktop.org \
--cc=hch@lst.de \
--cc=jglisse@redhat.com \
--cc=kvm-ppc@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=nouveau@lists.freedesktop.org \
--cc=rcampbell@nvidia.com \
/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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).