On 12.11.24 15:40, Patrick Roy wrote:
Hi David,
sorry for the late response, I ended up catching the flu last week and
was out of commission for a while :(
On Mon, 2024-11-04 at 21:30 +0000, David Hildenbrand wrote:
We talked about shared (faultable) vs. private (unfaultable), and how it
would interact with the directmap patches here.
As discussed, having private (unfaultable) memory with the direct-map
removed and shared (faultable) memory with the direct-mapping can make
sense for non-TDX/AMD-SEV/... non-CoCo use cases. Not sure about CoCo,
the discussion here seems to indicate that it might currently not be
required.
So one thing we could do is that shared (faultable) will have a direct
mapping and be gup-able and private (unfaultable) memory will not have a
direct mapping and is, by design, not gup-able.>
Maybe it could make sense to not have a direct map for all guest_memfd
memory, making it behave like secretmem (and it would be easy to
implement)? But I'm not sure if that is really desirable in VM context.
This would work for us (in this scenario, the swiotlb areas would be
"traditional" memory, e.g. set to shared via mem attributes instead of
"shared" inside KVM), it's kinda what I had prototyped in my v1 of this
series (well, we'd need to figure out how to get the mappings of gmem
back into KVM, since in this setup, short-circuiting it into
userspace_addr wouldn't work, unless we banish swiotlb into a different
memslot altogether somehow).
Right.
"right" as in, "yes we could do that"? :p
"right" as in "I see how that could work" :)
[...]
I remember talking to someone at some point about whether we could reuse
the proc-local stuff for guest memory, but I cannot remember the outcome
of that discussion... (or maybe I just wanted to have a discussion about
it, but forgot to follow up on that thought?). I guess we wouldn't use
proc-local _allocations_, but rather just set up proc-local mappings of
the gmem allocations that have been removed from the direct map.
Yes. And likely only for memory we really access / try access, if possible.
I'm wondering, where exactly would be the differences to Sean's idea
about messing with the CR3 register inside KVM to temporarily install
page tables that contain all the gmem stuff, conceptually? Wouldn't we
run into the same interrupt problems that Sean foresaw for the CR3
stuff? (which, admittedly, I still don't quite follow what these are :(
).
I'd need some more details on that. If anything would rely on the direct
mapping (from IRQ context?) than ... we obviously cannot remove the
direct mapping :)
--
Cheers,
David / dhildenb
