search for: mmu_interval_read_retri

From: Jason Gunthorpe <jgg at mellanox.com> Of the 13 users of mmu_notifiers, 8 of them use only invalidate_range_start/end() and immediately intersect the mmu_notifier_range with some kind of internal list of VAs. 4 use an interval tree (i915_gem, radeon_mn, umem_odp, hfi1). 4 use a linked list of some kind (scif_dma, vhost, gntdev, hmm) And the remaining 5 either don't use

On Tue, Apr 21, 2020 at 09:21:43PM -0300, Jason Gunthorpe wrote: > From: Jason Gunthorpe <jgg at mellanox.com> > > hmm_vma_walk->last is supposed to be updated after every write to the > pfns, so that it can be returned by hmm_range_fault(). However, this is > not done consistently. Fortunately nothing checks the return code of > hmm_range_fault() for anything other

On Mon, Jan 13, 2020 at 02:47:01PM -0800, Ralph Campbell wrote: > diff --git a/mm/mmu_notifier.c b/mm/mmu_notifier.c > index 47ad9cc89aab..4efecc0f13cb 100644 > +++ b/mm/mmu_notifier.c > @@ -1171,6 +1171,39 @@ void mmu_interval_notifier_update(struct mmu_interval_notifier *mni, > } > EXPORT_SYMBOL_GPL(mmu_interval_notifier_update); > > +struct mmu_interval_notifier

From: Jason Gunthorpe <jgg at mellanox.com> 8 of the mmu_notifier using drivers (i915_gem, radeon_mn, umem_odp, hfi1, scif_dma, vhost, gntdev, hmm) drivers are using a common pattern where they only use invalidate_range_start/end and immediately check the invalidating range against some driver data structure to tell if the driver is interested. Half of them use an interval_tree, the others

On 1/14/20 4:49 AM, Jason Gunthorpe wrote: > On Mon, Jan 13, 2020 at 02:47:01PM -0800, Ralph Campbell wrote: >> diff --git a/mm/mmu_notifier.c b/mm/mmu_notifier.c >> index 47ad9cc89aab..4efecc0f13cb 100644 >> +++ b/mm/mmu_notifier.c >> @@ -1171,6 +1171,39 @@ void mmu_interval_notifier_update(struct mmu_interval_notifier *mni, >> } >>

From: Jason Gunthorpe <jgg at mellanox.com> Convert the collision-retry lock around hmm_range_fault to use the one now provided by the mmu_interval notifier. Although this driver does not seem to use the collision retry lock that hmm provides correctly, it can still be converted over to use the mmu_interval_notifier api instead of hmm_mirror without too much trouble. This also deletes

From: Jason Gunthorpe <jgg at mellanox.com> The API is a bit complicated for the uses we actually have, and disucssions for simplifying have come up a number of times. This small series removes the customizable pfn format and simplifies the return code of hmm_range_fault() All the drivers are adjusted to process in the simplified format. I would appreciated tested-by's for the two

From: Jason Gunthorpe <jgg at mellanox.com> hmm_vma_walk->last is supposed to be updated after every write to the pfns, so that it can be returned by hmm_range_fault(). However, this is not done consistently. Fortunately nothing checks the return code of hmm_range_fault() for anything other than error. More importantly last must be set before returning -EBUSY as it is used to prevent

From: Jason Gunthorpe <jgg at mellanox.com> hmm_vma_walk->last is supposed to be updated after every write to the pfns, so that it can be returned by hmm_range_fault(). However, this is not done consistently. Fortunately nothing checks the return code of hmm_range_fault() for anything other than error. More importantly last must be set before returning -EBUSY as it is used to prevent

From: Jason Gunthorpe <jgg at mellanox.com> The only two users of this are now converted to use mmu_interval_notifier, delete all the code and update hmm.rst. Reviewed-by: J?r?me Glisse <jglisse at redhat.com> Tested-by: Ralph Campbell <rcampbell at nvidia.com> Signed-off-by: Jason Gunthorpe <jgg at mellanox.com> --- Documentation/vm/hmm.rst | 105 ++++-----------

From: Jason Gunthorpe <jgg at mellanox.com> Presumably the intent here was that hmm_range_fault() could put the data into some HW specific format and thus avoid some work. However, nothing actually does that, and it isn't clear how anything actually could do that as hmm_range_fault() provides CPU addresses which must be DMA mapped. Perhaps there is some special HW that does not need

From: Jason Gunthorpe <jgg at mellanox.com> Presumably the intent here was that hmm_range_fault() could put the data into some HW specific format and thus avoid some work. However, nothing actually does that, and it isn't clear how anything actually could do that as hmm_range_fault() provides CPU addresses which must be DMA mapped. Perhaps there is some special HW that does not need

From: Jason Gunthorpe <jgg at mellanox.com> The API is a bit complicated for the uses we actually have, and disucssions for simplifying have come up a number of times. This small series removes the customizable pfn format and simplifies the return code of hmm_range_fault() All the drivers are adjusted to process in the simplified format. I would appreciated tested-by's for the two

[+Philip Yang] Am 2020-04-21 um 8:21 p.m. schrieb Jason Gunthorpe: > From: Jason Gunthorpe <jgg at mellanox.com> > > Presumably the intent here was that hmm_range_fault() could put the data > into some HW specific format and thus avoid some work. However, nothing > actually does that, and it isn't clear how anything actually could do that > as hmm_range_fault()

This series adds new functions to the mmu interval notifier API to allow device drivers with MMUs to dynamically mirror a process' page tables based on device faults and invalidation callbacks. The Nouveau driver is updated to use the extended API and a set of stand alone self tests is added to help validate and maintain correctness. The patches are based on linux-5.5.0-rc6 and are for