On 13/09/2025 01:18, Vishal Annapurve wrote:
On Fri, Sep 12, 2025 at 8:39 AM David Hildenbrand <da...@redhat.com> wrote:
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?
I think what you explain below clarifies it.
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?
Thanks for clarifying, see below.
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.
Ah, okay. Yes, I recalled [1] that we wanted to change these semantics
to be "uptodate: was zeroed", and that preparation handling would be
essentially handled by the arch backend.
Yes, I think we should not be overloading uptodate flag to be an
indicator of what is private for CoCo guests. Uptodate flag should
just mean zeroed/fresh folio. It's possible that future allocator
backing for huge pages already provides uptodate folios.
Good point, thanks for sharing.
If there is no current use case for read/write for CoCo VMs, I think
it makes sense to disable it for now by checking the VM type before
adding further overloading of uptodate flags.
Sounds fair. I can add a check for the VM type and only allow it for
KVM_X86_SW_PROTECTED_VM on x86. When ARM CCA support [1] is added we
should also check for KVM_VM_TYPE_ARM_NORMAL on ARM.
[1]:
https://lore.kernel.org/kvm/20250820145606.180644-1-steven.pr...@arm.com
--
Cheers
David / dhildenb
