On Thu, 13 Aug 2015, Jérôme Glisse wrote:
> The invalidate_range_start() and invalidate_range_end() can be
> considered as forming an "atomic" section for the cpu page table
> update point of view. Between this two function the cpu page
> table content is unreliable for the address range being
>
On Mon, 29 Jun 2015, Jerome Glisse wrote:
> [...]
>
> Iterator is what protect against concurrent freeing of the directory so it
> has to return to caller on directory boundary (for 64bits arch with 64bits
> pte it has return every 512 entries). Otherwise pt_iter_fini() would have
> to walk ove
On Fri, 26 Jun 2015, Jerome Glisse wrote:
> On Thu, Jun 25, 2015 at 04:05:48PM -0700, Mark Hairgrove wrote:
> > On Thu, 21 May 2015, j.gli...@gmail.com wrote:
> > > From: Jérôme Glisse
> > > [...]
> > >
> > > + /* update() - update device mmu foll
On Fri, 26 Jun 2015, Jerome Glisse wrote:
> On Thu, Jun 25, 2015 at 03:57:29PM -0700, Mark Hairgrove wrote:
> > On Thu, 21 May 2015, j.gli...@gmail.com wrote:
> > > From: Jérôme Glisse
> > > [...]
> > > +
> > > +void hmm_pt_iter_init(struct hmm
On Thu, 21 May 2015, j.gli...@gmail.com wrote:
> From: Jérôme Glisse
>
> [...]
>
> + /* update() - update device mmu following an event.
> + *
> + * @mirror: The mirror that link process address space with the device.
> + * @event: The event that triggered the update.
> +
On Thu, 21 May 2015, j.gli...@gmail.com wrote:
> From: Jérôme Glisse
>
> [...]
> +
> +void hmm_pt_iter_init(struct hmm_pt_iter *iter);
> +void hmm_pt_iter_fini(struct hmm_pt_iter *iter, struct hmm_pt *pt);
> +unsigned long hmm_pt_iter_next(struct hmm_pt_iter *iter,
> +
On Fri, 19 Jun 2015, Jerome Glisse wrote:
> On Thu, Jun 18, 2015 at 07:06:08PM -0700, Mark Hairgrove wrote:
> > On Thu, 21 May 2015, j.gli...@gmail.com wrote:
>
> [...]
> > > +
> > > +static inline dma_addr_t hmm_pde_from_pfn(dma_addr_t pfn)
> >
DMA mapped entry and non mapped entry (pfn).
> - Split page directory entry and page table entry helpers.
>
> Signed-off-by: Jérôme Glisse
> Signed-off-by: Sherry Cheung
> Signed-off-by: Subhash Gutti
> Signed-off-by: Mark Hairgrove
> Signed-off-by: John Hubbard
On Thu, 11 Jun 2015, Jerome Glisse wrote:
> On Wed, Jun 10, 2015 at 06:15:08PM -0700, Mark Hairgrove wrote:
>
> [...]
> > > There is no race here, the mirror struct will only be freed once as again
> > > the list is a synchronization point. Whoever remove the mi
On Wed, 10 Jun 2015, Jerome Glisse wrote:
> [...]
>
> Like said, just ignore current code it is utterly broken in so many way
> when it comes to lifetime. I screw that part badly when reworking the
> patchset, i was focusing on other part.
>
> I fixed that in my tree, i am waiting for more rev
On Tue, 9 Jun 2015, Jerome Glisse wrote:
> On Mon, Jun 08, 2015 at 06:54:29PM -0700, Mark Hairgrove wrote:
> > Can you clarify how that's different from mmu_notifiers? Those are also
> > embedded into a driver-owned struct.
>
> For HMM you want to be able to kill a
On Mon, 8 Jun 2015, Jerome Glisse wrote:
> On Mon, Jun 08, 2015 at 12:40:18PM -0700, Mark Hairgrove wrote:
> >
> >
> > On Thu, 21 May 2015, j.gli...@gmail.com wrote:
> >
> > > From: Jérôme Glisse
> > >
> > > This patch only introduce cor
On Thu, 21 May 2015, j.gli...@gmail.com wrote:
> From: Jérôme Glisse
>
> This patch only introduce core HMM functions for registering a new
> mirror and stopping a mirror as well as HMM device registering and
> unregistering.
>
> [...]
>
> +/* struct hmm_device_operations - HMM device operation
13 matches
Mail list logo
