[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]
Re: UVM patch for PR port-xen/45975
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
> 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
Main Index |
Thread Index |