RE: [ANNOUNCE] PUCK Agenda - 2024.08.07 - KVM userfault (guest_memfd/HugeTLB postcopy)

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Thursday, August 8, 2024 1:22 AM, James Houghton wrote:
> On Thu, Aug 1, 2024 at 3:44 PM Sean Christopherson <seanjc@xxxxxxxxxx>
> wrote:
> >
> > Early warning for next week's PUCK since there's actually a topic this time.
> > James is going to lead a discussion on KVM userfault[*](name subject to
> change).
> 
> Thanks for attending, everyone!
> 
> We seemed to arrive at the following conclusions:
> 
> 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?




[Index of Archives]     [KVM ARM]     [KVM ia64]     [KVM ppc]     [Virtualization Tools]     [Spice Development]     [Libvirt]     [Libvirt Users]     [Linux USB Devel]     [Linux Audio Users]     [Yosemite Questions]     [Linux Kernel]     [Linux SCSI]     [XFree86]

  Powered by Linux