On 02/11/21 18:11, David Woodhouse wrote:
On Tue, 2021-11-02 at 18:01 +0100, Paolo Bonzini wrote:
On 02/11/21 17:38, David Woodhouse wrote:
This kind of makes a mockery of this
repeated map/unmap dance which I thought was supposed to avoid pinning
the page
The map/unmap dance is supposed to catch the moment where you'd look at
a stale cache, by giving the non-atomic code a chance to update the
gfn->pfn mapping.
It might have *chance* to do so, but it doesn't actually do it.
As noted, a GFN→PFN mapping is really a GFN→HVA→PFN mapping. And the
non-atomic code *does* update the GFN→HVA part of that, correctly
looking at the memslots generation etc..
But it pays absolutely no attention to the *second* part, and assumes
that the HVA→PFN mapping in the userspace page tables will never
change.
Which isn't necessarily true, even if the underlying physical page *is*
pinned to avoid most cases (ksm, swap, etc.) of the *kernel* changing
it. Userspace still can.
Yes, I agree. What I am saying is that:
- the map/unmap dance is not (entirely) about whether to pin the page
- the map/unmap API is not a bad API, just an incomplete implementation
And I think the above comment confuses both points above.
The unmap is also the moment where you can mark the page as dirty.
Sure, but it's the wrong page :)
The GFN _also_ has to be marked dirty.
Paolo
