On Tue, Mar 17, 2020 at 01:24:45PM +0100, Christoph Hellwig wrote:
> On Tue, Mar 17, 2020 at 09:15:36AM -0300, Jason Gunthorpe wrote:
> > > 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.
>
> No, with this series (and all actual callers before this series)
> we never fault in device private pages.
IFF we want to fault it in we'd need something like this. But I'd
really prefer to see test cases for that first.
diff --git a/mm/hmm.c b/mm/hmm.c
index b75b3750e03d..2884a3d11a1f 100644
--- a/mm/hmm.c
+++ b/mm/hmm.c
@@ -276,7 +276,7 @@ static int hmm_vma_handle_pte(struct mm_walk *walk, unsigned long addr,
if (!fault && !write_fault)
return 0;
- if (!non_swap_entry(entry))
+ if (!non_swap_entry(entry) || is_device_private_entry(entry))
goto fault;
if (is_migration_entry(entry)) {
