Re: [RFC PATCH v1 2/9] KVM: guest_memfd: Add guest_memfd support to kvm_(read|/write)_guest_page()

[David Hildenbrand <david@redhat.com>]

On 23.01.25 16:22, Patrick Roy wrote:
> On Thu, 2025-01-23 at 14:18 +0000, David Hildenbrand wrote:
>>>>>
>>>>> That said, we could always have a userspace address dedicated to
>>>>> mapping shared locations, and use that address when the necessity
>>>>> arises. Or we could always require that memslots have a userspace
>>>>> address, even if not used. I don't really have a strong preference.
>>>>
>>>> So, the simpler version where user space would simply mmap guest_memfd
>>>> to provide the address via userspace_addr would at least work for the
>>>> use case of paravirtualized time?
>>>
>>> fwiw, I'm currently prototyping something like this for x86 (although
>>> not by putting the gmem address into userspace_addr, but by adding a new
>>> field to memslots, so that memory attributes continue working), based on
>>> what we talked about at the last guest_memfd sync meeting (the whole
>>> "how to get MMIO emulation working for non-CoCo VMs in guest_memfd"
>>> story).
>>
>> Yes, I recall that discussion. Can you elaborate why the separate field
>> is required to keep memory attributes working? (could it be sorted out
>> differently, by reusing userspace_addr?).
> 
> The scenario I ran into was that within the same memslots, I wanted some
> gfns to be backed by guest_memfd, and others by traditional memory, so
> that KVM can GUP some parts of guest memory even if guest_memfd itself
> is direct map removed.

Just summarizing what we discussed yesterday:

GUP will not be allowed if the direct map was removed, and paravirt time 
on x86 uses GUP to access the guest page right now.

> 
> It actually also has to do with paravirtual time, but on x86. Here, the
> guest chooses where in guest memory the clock structure is placed via an
> MSR write (so I can't a priori use a traditional memslot, like we can on
> ARM).  KVM internally wants to GUP the hva that corresponds to the gfn
> the guest chooses, but if the hva is in a mapping of direct map removed
> gmem, that won't work.

And as discussed here, Sean raised that these hypervisor updates happen 
rarely.

In the first step, it might be good enough to just update using the 
user-space page table mappings (user access), to avoid messing with 
kmap/direct-map reinstalling.

With that in place, it looks like that user space could simply mmap 
guest_memfd and provide the mmaped area "ordinarily" as the "shared 
memory" part of the guest_memfd -- using userspace_address.

GUP would fail, bit paravirt time would not be using GUP.

So we could handle the guest_memfd mmap just like on other 
architectures, without the need for other memslot fields.

Please correct me if I misunderstood something :)

-- 
Cheers,

David / dhildenb