Message-ID: <DS0PR11MB6373A1908092810E99F387F7DCBA2@DS0PR11MB6373.namprd11.prod.outlook.com>
Date: Fri, 9 Aug 2024 13:51:48 +0000
From: "Wang, Wei W" <wei.w.wang@...el.com>
To: James Houghton <jthoughton@...gle.com>
CC: Sean Christopherson <seanjc@...gle.com>, "kvm@...r.kernel.org"
	<kvm@...r.kernel.org>, "linux-kernel@...r.kernel.org"
	<linux-kernel@...r.kernel.org>, Peter Xu <peterx@...hat.com>, Paolo Bonzini
	<pbonzini@...hat.com>, Oliver Upton <oliver.upton@...ux.dev>, Axel Rasmussen
	<axelrasmussen@...gle.com>, David Matlack <dmatlack@...gle.com>, "Anish
 Moorthy" <amoorthy@...gle.com>
Subject: RE: [ANNOUNCE] PUCK Agenda - 2024.08.07 - KVM userfault
 (guest_memfd/HugeTLB postcopy)

On Friday, August 9, 2024 3:05 AM, James Houghton wrote:
> On Thu, Aug 8, 2024 at 5:15 AM Wang, Wei W <wei.w.wang@...el.com> wrote:
> >
> > On Thursday, August 8, 2024 1:22 AM, James Houghton wrote:
> > > 1. For guest_memfd, stage 2 mapping installation will never go
> > > through GUP / virtual addresses to do the GFN --> PFN translation,
> > > including when it supports non-private memory.
> > > 2. Something like KVM Userfault is indeed necessary to handle
> > > post-copy for guest_memfd VMs, especially when guest_memfd supports
> > > non-private memory.
> > > 3. We should not hook into the overall GFN --> HVA translation, we
> > > should only be hooking the GFN --> PFN translation steps to figure
> > > out how to create stage 2 mappings. That is, KVM's own accesses to
> > > guest memory should just go through mm/userfaultfd.
> >
> > Sorry.. still a bit confused about this one: will gmem finally support GUP and
> VMA?
> > For 1. above, seems no, but for 3. here, KVM's own accesses to gmem
> > will go through userfaultfd via GUP?
> > Also, how would vhost's access to gmem get faulted to userspace?
> 
> Hi Wei,
> 
> From what we discussed in the meeting, guest_memfd will be mappable into
> userspace (so VMAs can be created for it), and so GUP will be able to work on
> it. However, KVM will *not* use GUP for doing gfn -> pfn translations for
> installing stage 2 mappings. (For guest-private memory, GUP cannot be used,
> but the claim is that GUP will never be used, no matter if it's guest-private or
> guest-shared.)

OK. For KVM userfault on a guest-shared page, how is a physical page gets filled
with the data (received from source) and installed into the host cr3 and guest
stage-2 page tables? Add a new gmem uAPI to achieve this?

There also seems to be a race condition between KVM userfault and userfaultfd.
For example, guest access to a guest-shared page triggers KVM userfault to
userspace while vhost (or KVM) could access to the same page during the window
that KVM userfault is handling the page, then there will be two simultaneous faults
on the same page.
I'm thinking how would this case be handled? (leaving it to userspace to detect and
handle such cases would be an complex)

> 
> KVM's own accesses to guest memory (i.e., places where it does
> copy_to/from_user) will go through GUP. By default, that's just how it would
> work. What I'm saying is that we aren't going to add anything extra to have
> "KVM Userfault" prevent KVM from doing a copy_to/from_user (like how I had
> it in the RFC, where KVM Userfault can block the translation of gfn -> hva).
> 
> vhost's accesses to guest memory will be the same as KVM's: it will go through
> copy_to/from_user.
> 
> Hopefully that's a little clearer. :)

Yeah, thanks for explanation. 
Enjoy your vacation. We can continue the discussion after that :)

Powered by blists - more mailing lists