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