Re: UVM patch for PR port-xen/45975

[Manuel Bouyer <bouyer%antioche.eu.org@localhost>]

On Mon, Feb 20, 2012 at 08:52:38PM +0000, Mindaugas Rasiukevicius wrote:
> 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?

I'm not sure what you mean, but Xen maintains a state (read/write, R/O
or PDP in guest) for each page. For bare metal, I guess it doens't
matter.

> There is no logical reason why page could not be freed while there is
> still an active mapping.

Exept if you want to make sure that nobody can use a not-yet-removed
mapping to write to the page.

> 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.

pmap_update() is fine when you care about the VA. It does not if
you care about the PA ...

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

the pmap doesn't know (especially as the allocation happens on a different
CPU). It doens't look like UVM can notify us when all operations
for a free page are complete.

-- 
Manuel Bouyer <bouyer%antioche.eu.org@localhost>
     NetBSD: 26 ans d'experience feront toujours la difference
--