On 20.06.24 15:55, Jason Gunthorpe wrote:
On Thu, Jun 20, 2024 at 09:32:11AM +0100, Fuad Tabba wrote:
Hi,
On Thu, Jun 20, 2024 at 5:11 AM Christoph Hellwig <hch@xxxxxxxxxxxxx> wrote:
On Wed, Jun 19, 2024 at 08:51:35AM -0300, Jason Gunthorpe wrote:
If you can't agree with the guest_memfd people on how to get there
then maybe you need a guest_memfd2 for this slightly different special
stuff instead of intruding on the core mm so much. (though that would
be sad)
Or we're just not going to support it at all. It's not like supporting
this weird usage model is a must-have for Linux to start with.
Sorry, but could you please clarify to me what usage model you're
referring to exactly, and why you think it's weird? It's just that we
have covered a few things in this thread, and to me it's not clear if
you're referring to protected VMs sharing memory, or being able to
(conditionally) map a VM's memory that's backed by guest_memfd(), or
if it's the Exclusive pin.
Personally I think mapping memory under guest_memfd is pretty weird.
I don't really understand why you end up with something different than
normal CC. Normal CC has memory that the VMM can access and memory it
cannot access. guest_memory is supposed to hold the memory the VMM cannot
reach, right?
So how does normal CC handle memory switching between private and
shared and why doesn't that work for pKVM? I think the normal CC path
effectively discards the memory content on these switches and is
slow. Are you trying to make the switch content preserving and faster?
If yes, why? What is wrong with the normal CC model of slow and
non-preserving shared memory?
I'll leave the !huge page part to Fuad.
Regarding huge pages: assume the huge page (e.g., 1 GiB hugetlb) is
shared, now the VM requests to make one subpage private. How to handle
that without eventually running into a double memory-allocation? (in the
worst case, allocating a 1GiB huge page for shared and for private memory).
In the world of RT, you want your VM to be consistently backed by
huge/gigantic mappings, not some weird mixture -- so I've been told by
our RT team.
(there are more issues with huge pages in the style hugetlb, where we
actually want to preallocate all pages and not rely on dynamic
allocation at runtime when we convert back and forth between shared and
private)
--
Cheers,
David / dhildenb
