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
