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.