Re: [PATCH v4 2/2] mm/hmm/test: add self tests for HMM

[Ralph Campbell <rcampbell@nvidia.com>]

On 11/13/19 5:51 AM, Christoph Hellwig wrote:
> On Tue, Nov 12, 2019 at 11:45:52PM +0000, Jason Gunthorpe wrote:
>>> Well, it would mean registering for the whole process address space.
>>> I'll give it a try.
>>
>> I'm not sure it makes much sense that this testing is essentially
>> modeled after nouveau's usage which is very strange compared to the
>> other drivers.
> 
> Which means we really should make the test cases fit the proper usage.
> Maybe defer the tests for 5.5 and just merge the first patch for now?
> 

I think this a good point to discuss.
Some devices will want to register for all changes to the process address
space because there is no requirement to preregister regions that the
device can access verses devices like InfiniBand where a range of addresses
have to be registered before the device can access those addresses.
So for nouveau and the hmm-test driver, the mmu_range_notifier_insert()
and mmu_range_notifier_remove() are only used long enough to get a
stable copy of a small part of the process address space and copy it to
the device's page table. Then the regular process wide invalidations are
required to keep the device's page tables consistent with the process
page table.

The "hacky" part of the current design is the interaction between the
short term narrow address range invalidations verses the long term
process wide invalidations. (double callbacks, double locking of the
device page table)

Both types of invalidate callbacks seem useful to me so forcing a
driver to use only one type doesn't make sense to me.