Re: [RFC PATCH v1 0/9] KVM: Mapping of guest_memfd at the host and a software protected VM type

David Hildenbrand
2025-01-22T15:42:00Z

On 22.01.25 16:35, David Hildenbrand wrote:
> On 22.01.25 16:27, Fuad Tabba wrote:
>> The purpose of this series is to serve as a potential base for
>> restricted mmap() support for guest_memfd [1]. It would allow
>> experimentation with what that support would be like, in the safe
>> environment of a new VM type used for testing.
>>
>> This series adds a new VM type for arm64,
>> KVM_VM_TYPE_ARM_SW_PROTECTED, analogous to the x86
>> KVM_X86_SW_PROTECTED_VM. This type is to serve as a development
>> and testing vehicle for Confidential (CoCo) VMs.
>>
>> Similar to the x86 type, this is currently only for development
>> and testing. It's not meant to be used for "real" VMs, and
>> especially not in production. The behavior and effective ABI for
>> software-protected VMs is unstable.
>>
>> This series enables mmap() support for guest_memfd specifically
>> for the new software-protected VM type, only when explicitly
>> enabled in the config.
>
> Hi!
>
> IIUC, in this series, there is no "private" vs "shared" distinction,
> right? So all pages are mappable, and "conversion" does not exist?

Ah, I spot:

+#define kvm_arch_private_mem_inplace(kvm) \
+ (IS_ENABLED(CONFIG_KVM_GMEM_MAPPABLE) && \
+ ((kvm)->arch.vm_type & KVM_VM_TYPE_ARM_SW_PROTECTED))

Which makes me wonder, why don't we need the same way of making sure all
references/mappings are gone (+ new page type) when doing the shared ->
private conversion? Or is this somewhere in here where I didn't spot it yet?

--
Cheers,

David / dhildenb