Re: tracking P->V for unmanaged device pages

[Masao Uebayashi <uebayasi%gmail.com@localhost>]

On Thu, Apr 9, 2015 at 11:46 AM, Taylor R Campbell
<campbell+netbsd-tech-kern%mumble.net@localhost> wrote:
>    > In my pmap_pv API, there's no need to change pmap_enter.  All you need
>    > to do is to call pmap_pv_track on driver attach to mark the pages as
>    > device pages.  Then pmap can do the bookkeeping inside.
>
>    You don't need to change pmap_enter(), but you need to change fault
>    handlers.  That didn't really work for XIP, which has to share the
>    generic fault handler.
>
> I don't understand.  Why do you need to change fault handlers?  I
> think the only real reason the drm drivers need custom fault handlers
> is that they need to hold a lock over pinning graphics buffers in GPU
> VA and entering the corresponding aperture PAs into the pmap, and
> neither the cdev_mmap nor pgo_getpages/putpages abstraction supports
> this.

Sorry, I misunderstood...  pmap_pv_tracked() is called from
pmap_enter() so it's already doing what I wanted (the name
pmap_pv_tracked() is not great though).

> Is the uebayasi-xip branch relevant?  Are there changes there which
> might be instructive?

Not really.

>    > It sounds like what you're proposing is to replace pmap_pv_track by a
>    > version of uvm_page_physload that will not allocate struct vm_page for
>    > each page in the region, but only struct vm_pv.  I have no objection
>    > to this either, but someone has to do the work.
>
>    It doesn't need to be done quickly.  I just want to know the
>    direction.  The abstraction of physical address and memory in UVM is
>    very poor ATM.  I want to change that, and want awareness of the
>    problem.  (Future memory technologies like persistent memory is coming
>    soon.)
>
> I don't have enough background to make any statements about the
> direction.