search for: migrate_vma_from_device_priv

...; + mig.dir = MIGRATE_VMA_FROM_SYSTEM; /* * We come here with mmap_lock write lock held just for @@ -578,6 +579,7 @@ kvmppc_svm_page_out(struct vm_area_struct *vma, unsigned long start, mig.src = &src_pfn; mig.dst = &dst_pfn; mig.src_owner = &kvmppc_uvmem_pgmap; + mig.dir = MIGRATE_VMA_FROM_DEVICE_PRIVATE; mutex_lock(&kvm->arch.uvmem_lock); /* The requested page is already paged-out, nothing to do */ diff --git a/drivers/gpu/drm/nouveau/nouveau_dmem.c b/drivers/gpu/drm/nouveau/nouveau_dmem.c index cc9993837508..762e0168bc8d 100644 --- a/drivers/gpu/drm/nouveau/nouveau_dmem.c +++ b/dr...

...; + mig.dir = MIGRATE_VMA_FROM_SYSTEM; /* * We come here with mmap_lock write lock held just for @@ -578,6 +579,7 @@ kvmppc_svm_page_out(struct vm_area_struct *vma, unsigned long start, mig.src = &src_pfn; mig.dst = &dst_pfn; mig.src_owner = &kvmppc_uvmem_pgmap; + mig.dir = MIGRATE_VMA_FROM_DEVICE_PRIVATE; mutex_lock(&kvm->arch.uvmem_lock); /* The requested page is already paged-out, nothing to do */ diff --git a/drivers/gpu/drm/nouveau/nouveau_dmem.c b/drivers/gpu/drm/nouveau/nouveau_dmem.c index e5c230d9ae24..e5c83b8ee82e 100644 --- a/drivers/gpu/drm/nouveau/nouveau_dmem.c +++ b/dr...

...gt; > /* > * We come here with mmap_lock write lock held just for > @@ -578,6 +579,7 @@ kvmppc_svm_page_out(struct vm_area_struct *vma, unsigned long start, > mig.src = &src_pfn; > mig.dst = &dst_pfn; > mig.src_owner = &kvmppc_uvmem_pgmap; > + mig.dir = MIGRATE_VMA_FROM_DEVICE_PRIVATE; > > mutex_lock(&kvm->arch.uvmem_lock); > /* The requested page is already paged-out, nothing to do */ > diff --git a/drivers/gpu/drm/nouveau/nouveau_dmem.c b/drivers/gpu/drm/nouveau/nouveau_dmem.c > index e5c230d9ae24..e5c83b8ee82e 100644 > +++ b/drivers/gpu/drm/n...

...* We come here with mmap_lock write lock held just for >> @@ -578,6 +579,7 @@ kvmppc_svm_page_out(struct vm_area_struct *vma, unsigned long start, >> mig.src = &src_pfn; >> mig.dst = &dst_pfn; >> mig.src_owner = &kvmppc_uvmem_pgmap; >> + mig.dir = MIGRATE_VMA_FROM_DEVICE_PRIVATE; >> >> mutex_lock(&kvm->arch.uvmem_lock); >> /* The requested page is already paged-out, nothing to do */ >> diff --git a/drivers/gpu/drm/nouveau/nouveau_dmem.c b/drivers/gpu/drm/nouveau/nouveau_dmem.c >> index e5c230d9ae24..e5c83b8ee82e 100644 >&...

The goal for this series is to avoid device private memory TLB invalidations when migrating a range of addresses from system memory to device private memory and some of those pages have already been migrated. The approach taken is to introduce a new mmu notifier invalidation event type and use that in the device driver to skip invalidation callbacks from migrate_vma_setup(). The device driver is

The goal for this series is to avoid device private memory TLB invalidations when migrating a range of addresses from system memory to device private memory and some of those pages have already been migrated. The approach taken is to introduce a new mmu notifier invalidation event type and use that in the device driver to skip invalidation callbacks from migrate_vma_setup(). The device driver is

....h > > > @@ -180,6 +180,11 @@ static inline unsigned long migrate_pfn(unsigned long pfn) > > > return (pfn << MIGRATE_PFN_SHIFT) | MIGRATE_PFN_VALID; > > > } > > > +enum migrate_vma_direction { > > > + MIGRATE_VMA_FROM_SYSTEM, > > > + MIGRATE_VMA_FROM_DEVICE_PRIVATE, > > > +}; > > > > I would have guessed this is more natural as _FROM_DEVICE_ and > > TO_DEVICE_ ? > > The caller controls where the destination memory is allocated so it isn't > necessarily device private memory, it could be from system to system. >...

...er when working with DEVICE_PRIVATE? But then the comment in the prior patch should be fixed: @@ -199,11 +204,12 @@ struct migrate_vma { /* * Set to the owner value also stored in page->pgmap->owner for + * migrating device private memory. The direction also needs to + * be set to MIGRATE_VMA_FROM_DEVICE_PRIVATE. To say the caller must always provide src_owner. And that field should probably be renamed at this point, as there is nothing "src" about it. It is just the pgmap_owner of the DEVICE_PRIVATE pages the TO/FROM DEVICE migration is working on. Jason

...unsigned long migrate_pfn(unsigned long pfn) > > > > > return (pfn << MIGRATE_PFN_SHIFT) | MIGRATE_PFN_VALID; > > > > > } > > > > > +enum migrate_vma_direction { > > > > > + MIGRATE_VMA_FROM_SYSTEM, > > > > > + MIGRATE_VMA_FROM_DEVICE_PRIVATE, > > > > > +}; > > > > > > > > I would have guessed this is more natural as _FROM_DEVICE_ and > > > > TO_DEVICE_ ? > > > > > > The caller controls where the destination memory is allocated so it isn't > > > neces...

...;> @@ -180,6 +180,11 @@ static inline unsigned long migrate_pfn(unsigned long pfn) >>>> return (pfn << MIGRATE_PFN_SHIFT) | MIGRATE_PFN_VALID; >>>> } >>>> +enum migrate_vma_direction { >>>> + MIGRATE_VMA_FROM_SYSTEM, >>>> + MIGRATE_VMA_FROM_DEVICE_PRIVATE, >>>> +}; >>> >>> I would have guessed this is more natural as _FROM_DEVICE_ and >>> TO_DEVICE_ ? >> >> The caller controls where the destination memory is allocated so it isn't >> necessarily device private memory, it could be from sy...

...nsigned long migrate_pfn(unsigned long pfn) >>>>>> return (pfn << MIGRATE_PFN_SHIFT) | MIGRATE_PFN_VALID; >>>>>> } >>>>>> +enum migrate_vma_direction { >>>>>> + MIGRATE_VMA_FROM_SYSTEM, >>>>>> + MIGRATE_VMA_FROM_DEVICE_PRIVATE, >>>>>> +}; >>>>> >>>>> I would have guessed this is more natural as _FROM_DEVICE_ and >>>>> TO_DEVICE_ ? >>>> >>>> The caller controls where the destination memory is allocated so it isn't >>>&gt...