On Sat, Jul 30, 2016 at 03:10:45PM +0200, Mark Kettenis wrote: > > From: Philip Guenther <[email protected]> > > Date: Fri, 29 Jul 2016 15:41:48 -0700 > > > > On Fri, Jul 29, 2016 at 3:31 PM, Mark Kettenis <[email protected]> > > wrote: > > >> Date: Thu, 28 Jul 2016 09:47:42 +0200 > > >> From: Patrick Wildt <[email protected]> > > >> > > >> There is something I missed in the previous diff. When the PTE is not > > >> valid, the mapping behind the virtual address of course isn't valid. > > >> A flush to an unmapped page will give us a translation fault. So only > > >> flush if the page was active. > > >> > > >> ok? > > > > > > I'm not sure this is right. If the page has been modified we may need > > > to flush the cache. > > > > If a modified page is invalidated, won't it be flushed then? Can we > > really have modified, but invalid pages? > > Page table entries are marked as invalid to emulate the referenced bit > that the hardware doesn't implement. This happens when the referenced > bit gets cleared; in fact most managed pages start out that way. > Whenever the page gets accessed we will fault, set the referenced bit > and clear the invalid bit in the page table entry. >
This doesn't matter, but actually there's no invalid bit, so invalid = lack of bits describing the type of an entry. And fwiw. i've got a branch from 2013 w/PVF_REF bit in the pte itself, look for SCTLR.AFE if you care(freebsd also took this 'Access Flag' route). -Artturi > There is noo need to flush pages that haven't been touched. However, > if we modify a page and the pagedaemon comes by and clears the > referenced bit, we may end up with an invalid mapping of a page that > still has data that in the cache that has not been written back to > memory. > > That said, it does seem as if the code that clears the referenced bit > already writes back the cache lines before it invalidates the mapping. > See the > > if (maskbits & PVF_REF) > > code in pmap_clearbit(). So it seems there is no problem after all. >
