Re: [PATCH v5 4/9] KVM: guest_memfd: Handle in-place shared memory as guest_memfd backed memory

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

 



Hi Ackerley,

On Thu, 6 Mar 2025 at 16:09, Ackerley Tng <ackerleytng@xxxxxxxxxx> wrote:
>
> Fuad Tabba <tabba@xxxxxxxxxx> writes:
>
> > For VMs that allow sharing guest_memfd backed memory in-place,
> > handle that memory the same as "private" guest_memfd memory. This
> > means that faulting that memory in the host or in the guest will
> > go through the guest_memfd subsystem.
> >
> > Note that the word "private" in the name of the function
> > kvm_mem_is_private() doesn't necessarily indicate that the memory
> > isn't shared, but is due to the history and evolution of
> > guest_memfd and the various names it has received. In effect,
> > this function is used to multiplex between the path of a normal
> > page fault and the path of a guest_memfd backed page fault.
> >
>
> I think this explanation is a good summary, but this change seems to
> make KVM take pages via guest_memfd functions for more than just
> guest-private pages.
>
> This change picks the guest_memfd fault path as long as the memslot has
> an associated guest_memfd (kvm_slot_can_be_private()) and gmem was
> configured to kvm_arch_gmem_supports_shared_mem().
>
> For shared accesses, shouldn't KVM use the memslot's userspace_addr?
> It's still possibly the same mmap-ed guest_memfd inode, but via
> userspace_addr. And for special accesses from within KVM (e.g. clock),
> maybe some other changes are required inside KVM, or those could also
> use userspace_addr.

The reason is that, although it does have a userspace_addr, it might
not actually be mapped. We don't require that shared memory be mapped.

Cheers,
/fuad


> You mentioned that pKVM doesn't use
> KVM_GENERIC_MEMORY_ATTRIBUTES/mem_attr_array, so perhaps the change
> required here is that kvm_mem_is_private() should be updated to
> kvm_slot_can_be_private() && whatever pKVM uses to determine if a gfn is
> private?
>
> So perhaps kvm_arch_gmem_supports_shared_mem() should be something like
> kvm_arch_gmem_use_guest_memfd(), where x86 would override that to use
> mem_attr_array if CONFIG_KVM_GENERIC_MEMORY_ATTRIBUTES is selected?
>
> >
> > Signed-off-by: Fuad Tabba <tabba@xxxxxxxxxx>
> > ---
> >  include/linux/kvm_host.h | 3 ++-
> >  1 file changed, 2 insertions(+), 1 deletion(-)
> >
> > diff --git a/include/linux/kvm_host.h b/include/linux/kvm_host.h
> > index 2d025b8ee20e..296f1d284d55 100644
> > --- a/include/linux/kvm_host.h
> > +++ b/include/linux/kvm_host.h
> > @@ -2521,7 +2521,8 @@ static inline bool kvm_mem_is_private(struct kvm *kvm, gfn_t gfn)
> >  #else
> >  static inline bool kvm_mem_is_private(struct kvm *kvm, gfn_t gfn)
> >  {
> > -     return false;
> > +     return kvm_arch_gmem_supports_shared_mem(kvm) &&
> > +            kvm_slot_can_be_private(gfn_to_memslot(kvm, gfn));
> >  }
> >  #endif /* CONFIG_KVM_GENERIC_MEMORY_ATTRIBUTES */




[Index of Archives]     [Linux ARM Kernel]     [Linux ARM]     [Linux Omap]     [Fedora ARM]     [IETF Annouce]     [Bugtraq]     [Linux OMAP]     [Linux MIPS]     [eCos]     [Asterisk Internet PBX]     [Linux API]

  Powered by Linux