Re: [RFC] mm/hmm: pass mmu_notifier_range to sync_cpu_device_pagetables

2019-07-04 Thread Jason Gunthorpe
On Wed, Jul 03, 2019 at 02:27:22AM +, Kuehling, Felix wrote: > On 2019-07-02 6:59 p.m., Jason Gunthorpe wrote: > > On Wed, Jul 03, 2019 at 12:49:12AM +0200, Christoph Hellwig wrote: > >> On Tue, Jul 02, 2019 at 07:53:23PM +, Jason Gunthorpe wrote: > I'm sending this out now since we

Re: [RFC] mm/hmm: pass mmu_notifier_range to sync_cpu_device_pagetables

2019-07-03 Thread Jason Gunthorpe
On Wed, Jul 03, 2019 at 12:49:12AM +0200, Christoph Hellwig wrote: > On Tue, Jul 02, 2019 at 07:53:23PM +, Jason Gunthorpe wrote: > > > I'm sending this out now since we are updating many of the HMM APIs > > > and I think it will be useful. > > > > This make so much sense, I'd like to apply

Re: [RFC] mm/hmm: pass mmu_notifier_range to sync_cpu_device_pagetables

2019-07-03 Thread Ralph Campbell
On 7/2/19 12:53 PM, Jason Gunthorpe wrote: On Fri, Jun 07, 2019 at 05:14:52PM -0700, Ralph Campbell wrote: HMM defines its own struct hmm_update which is passed to the sync_cpu_device_pagetables() callback function. This is sufficient when the only action is to invalidate. However, a device

Re: [RFC] mm/hmm: pass mmu_notifier_range to sync_cpu_device_pagetables

2019-07-03 Thread Jason Gunthorpe
On Fri, Jun 07, 2019 at 05:14:52PM -0700, Ralph Campbell wrote: > HMM defines its own struct hmm_update which is passed to the > sync_cpu_device_pagetables() callback function. This is > sufficient when the only action is to invalidate. However, > a device may want to know the reason for the

Re: [RFC] mm/hmm: pass mmu_notifier_range to sync_cpu_device_pagetables

2019-07-02 Thread Kuehling, Felix
On 2019-07-02 6:59 p.m., Jason Gunthorpe wrote: > On Wed, Jul 03, 2019 at 12:49:12AM +0200, Christoph Hellwig wrote: >> On Tue, Jul 02, 2019 at 07:53:23PM +, Jason Gunthorpe wrote: I'm sending this out now since we are updating many of the HMM APIs and I think it will be useful. >>>

Re: [RFC] mm/hmm: pass mmu_notifier_range to sync_cpu_device_pagetables

2019-06-10 Thread John Hubbard
On 6/8/19 4:41 AM, Jason Gunthorpe wrote: > On Sat, Jun 08, 2019 at 02:10:08AM -0700, Christoph Hellwig wrote: >> On Fri, Jun 07, 2019 at 05:14:52PM -0700, Ralph Campbell wrote: >>> HMM defines its own struct hmm_update which is passed to the >>> sync_cpu_device_pagetables() callback function.

Re: [RFC] mm/hmm: pass mmu_notifier_range to sync_cpu_device_pagetables

2019-06-09 Thread Ira Weiny
On Fri, Jun 07, 2019 at 05:14:52PM -0700, Ralph Campbell wrote: > HMM defines its own struct hmm_update which is passed to the > sync_cpu_device_pagetables() callback function. This is > sufficient when the only action is to invalidate. However, > a device may want to know the reason for the

Re: [RFC] mm/hmm: pass mmu_notifier_range to sync_cpu_device_pagetables

2019-06-09 Thread Jason Gunthorpe
On Sat, Jun 08, 2019 at 02:10:08AM -0700, Christoph Hellwig wrote: > On Fri, Jun 07, 2019 at 05:14:52PM -0700, Ralph Campbell wrote: > > HMM defines its own struct hmm_update which is passed to the > > sync_cpu_device_pagetables() callback function. This is > > sufficient when the only action is

[RFC] mm/hmm: pass mmu_notifier_range to sync_cpu_device_pagetables

2019-06-09 Thread Ralph Campbell
HMM defines its own struct hmm_update which is passed to the sync_cpu_device_pagetables() callback function. This is sufficient when the only action is to invalidate. However, a device may want to know the reason for the invalidation and be able to see the new permissions on a range, update device

Re: [RFC] mm/hmm: pass mmu_notifier_range to sync_cpu_device_pagetables

2019-06-09 Thread Jason Gunthorpe
On Fri, Jun 07, 2019 at 05:14:52PM -0700, Ralph Campbell wrote: > HMM defines its own struct hmm_update which is passed to the > sync_cpu_device_pagetables() callback function. This is > sufficient when the only action is to invalidate. However, > a device may want to know the reason for the