Re: UVM patch for PR port-xen/45975

[Mindaugas Rasiukevicius <rmind%netbsd.org@localhost>]

Manuel Bouyer <bouyer%antioche.eu.org@localhost> wrote:
> > since pmap_kremove() can defer its effects (though I guess it currently
> > doesn't for xen, since otherwise your latest patch wouldn't work?  not
> > sure, I haven't found the code yet), I would think we would need to
> > call pmap_update() before freeing the page in this code.
> 
> Right, for x86 (Xen or native)  pmap_kremove writes the PTEs immediatly,
> but defer tlb invalidations. In case of Xen, tlb invalidations is done by
> the hypervisor if needed when reusing the page as PDP.

Well, V->P mapping does not imply the state of physical page, does it?
There is no logical reason why page could not be freed while there is
still an active mapping.  It is pmap_update() which indicates the point
where mappings must be or become visible.  Which is the point when *VA*,
not the page, becomes available for reuse.  So, on the second thought
about reversed way being cleaner.. I think the purpose of pmap_update()
call itself clarifies that it is not necessary cleaner.

Thinking of Xen case specifically.. I wonder, perhaps it can be ensured
that there are no mappings at PDP allocation point?

-- 
Mindaugas