Re: [PATCH v5 1/2] KVM: guest_memfd: add generic population via write

[Nikita Kalyazin <kalyazin@amazon.com>]

On 12/09/2025 14:36, David Hildenbrand wrote:
> On 11.09.25 12:15, Nikita Kalyazin wrote:
>>
>>
>> On 10/09/2025 22:23, James Houghton wrote:
>>> On Tue, Sep 2, 2025 at 4:20 AM Kalyazin, Nikita 
>>> <kalyazin@amazon.co.uk> wrote:
>>>>
>>>> From: Nikita Kalyazin <kalyazin@amazon.com>
>>>
>>> Hi Nikita,
>>
>> Hi James,
>>
>> Thanks for the review!
>>
>>
>>>>
>>>> write syscall populates guest_memfd with user-supplied data in a 
>>>> generic
>>>> way, ie no vendor-specific preparation is performed.  This is supposed
>>>> to be used in non-CoCo setups where guest memory is not
>>>> hardware-encrypted.
>>>
>>> What's meant to happen if we do use this for CoCo VMs? I would expect
>>> write() to fail, but I don't see why it would (seems like we need/want
>>> a check that we aren't write()ing to private memory).
>>
>> I am not so sure that write() should fail even in CoCo VMs if we access
>> not-yet-prepared pages.  My understanding was that the CoCoisation of
>> the memory occurs during "preparation".  But I may be wrong here.
> 
> But how do you handle that a page is actually inaccessible and should
> not be touched?
> 
> IOW, with CXL you could crash the host.
> 
> There is likely some state check missing, or it should be restricted to
> VM types.

Sorry, I'm missing the link between VM types and CXL.  How are they related?

My thinking was it is a regular (accessible) page until it is "prepared" 
by the CoCo hardware, which is currently tracked by the up-to-date flag, 
so it is safe to assume that until it is "prepared", it is accessible 
because it was allocated by filemap_grab_folio() -> 
filemap_alloc_folio() and hasn't been taken over by the CoCo hardware. 
What scenario can you see where it doesn't apply as of now?

I am aware of an attempt to remove preparation tracking from 
guest_memfd, but it is still at an RFC stage AFAIK [1].

> 
> Do we know how this would interact with the direct-map removal?

I'm using folio_test_uptodate() to determine if the page has been 
removed from the direct map as kvm_gmem_mark_prepared() is what 
currently removes the page from the direct map and marks it as 
up-to-date.  [2] is a Firecracker feature branch where the two work in 
combination.

[1]: https://lore.kernel.org/kvm/20250715225523.yzmrwghbhi56tqux@amd.com
[2]: 
https://github.com/firecracker-microvm/firecracker/tree/feature/secret-hiding

> 
> -- 
> Cheers
> 
> David / dhildenb
>