[RFC PATCH v3 0/6] Direct Map Removal for guest_memfd

[David Hildenbrand]

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