Re: [PATCH v5 5/5] KVM: PPC: e500: MMU API

[Benjamin Herrenschmidt <benh@kernel.crashing.org>]

On Mon, 2011-08-15 at 10:03 -0500, Scott Wood wrote:
> On 08/13/2011 10:14 AM, Benjamin Herrenschmidt wrote:
> > On Mon, 2011-07-18 at 11:18 -0500, Scott Wood wrote:
> > 
> >>> Does this work? Why do we need to set them dirty in the first place? If the shared tlb pages are on file backed storage, we're screwed under memory pressure either way and they'd just get evicted despite us writing to them. Or does vmap pin them? Either way, they're either pinned or not. And if they're not, dirtying them here shouldn't really buy us anything, no?
> >>
> >> They're pinned by get_user_pages_fast().  We (potentially) write to them, so
> >> we should mark them dirty, because they are dirty.  It's up to the rest
> >> of Linux what to do with that.  Will being pinned stop updates from being
> >> written out if it is file-backed?  And eventually the vm will be destroyed
> >> (or the tlb reconfigured) and the pages will be unpinned.
> > 
> > Note that gup or gup_fast won't guarantee that the virtual->physical
> > mapping remains.
> > 
> > IE. the backing page itself will remain around, but it could be broken
> > off the mapping and another page can have taken its place in qemu
> > address space.
> > 
> > (Think page migration for example).
> 
> How would that work if gup is being used to implement read()?  Wouldn't
> the data be written to the wrong place?

If it drops the mm_sem, I suppose so. You'll have to talk to the vm
folks, they are the ones who warned me against gup.

Cheers,
Ben.