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. > The unmap is also the moment where you can mark the page as dirty. Sure, but it's the wrong page :) It's not necessarily the page that is at that userspace HVA, and hence in the guest's EPT at that GFN any more. In my Xen event channel series, I added a 'mmap a page from /dev/zero over the shared_info page after it's active' torture test to demonstrate this and check it was fixed. I suppose we could do the same in the steal_time test...?
Attachment:
smime.p7s
Description: S/MIME cryptographic signature
