On Mon, Feb 20, 2012 at 08:52:38PM +0000, Mindaugas Rasiukevicius wrote: > Manuel Bouyer <[email protected]> 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 <[email protected]> NetBSD: 26 ans d'experience feront toujours la difference --
