Michael Roth <[email protected]> writes:
>
> [...snip...]
>
>> static unsigned long kvm_get_vm_memory_attributes(struct kvm *kvm, gfn_t
>> gfn)
>> {
>> @@ -2635,6 +2625,8 @@ static int kvm_vm_ioctl_set_mem_attributes(struct kvm
>> *kvm,
>> return -EINVAL;
>> if (!PAGE_ALIGNED(attrs->address) || !PAGE_ALIGNED(attrs->size))
>> return -EINVAL;
>> + if (attrs->error_offset)
>> + return -EINVAL;
>> for (i = 0; i < ARRAY_SIZE(attrs->reserved); i++) {
>> if (attrs->reserved[i])
>> return -EINVAL;
>> @@ -4983,6 +4975,11 @@ static int
>> kvm_vm_ioctl_check_extension_generic(struct kvm *kvm, long arg)
>> return 1;
>> case KVM_CAP_GUEST_MEMFD_FLAGS:
>> return kvm_gmem_get_supported_flags(kvm);
>> + case KVM_CAP_GUEST_MEMFD_MEMORY_ATTRIBUTES:
>> + if (vm_memory_attributes)
>> + return 0;
>> +
>> + return kvm_supported_mem_attributes(kvm);
>
> Based on the discussion from the PUCK call this morning,
Thanks for copying the discussion here, I'll start attending PUCK to
catch those discussions too :)
> it sounds like it
> would be a good idea to limit kvm_supported_mem_attributes() to only
> reporting KVM_MEMORY_ATTRIBUTE_PRIVATE if the underlying CoCo
> implementation has all the necessary enablement to support in-place
> conversion via guest_memfd. In the case of SNP, there is a
> documentation/parameter check in snp_launch_update() that needs to be
> relaxed in order for userspace to be able to pass in a NULL 'src'
> parameter (since, for in-place conversion, it would be initialized in place
> as shared memory prior to the call, since by the time kvm_gmem_poulate()
> it will have been set to private and therefore cannot be faulted in via
> GUP (and if it could, we'd be unecessarily copying the src back on top
> of itself since src/dst are the same).
Could this be a separate thing? If I'm understanding you correctly, it's
not strictly a requirement for snp_launch_update() to first support a
NULL 'src' parameter before this series lands.
Without this series, the startup procedure is to have memory set up in
non-guest_memfd shared memory, and then snp_launch_update()-ed into
guest_memfd private memory.
With this series, it is a little troublesome, but the startup procedure
can still set up memory in guest_memfd shared memory, then copy
everything out to some temporary memory, then set guest_memfd memory to
private, then snp_launch_update() the temporary memory into guest_memfd
private memory.
We would be unnecessarily copying the src (now in some temporary memory)
back onto itself. Can that be a separate patch series?
Btw, if snp_launch_update() is going to accept a NULL src parameter and
launch-update the src in-place:
+ Will userspace have to set that memory to private before calling launch
update?
+ If yes, then would we need some other mode of conversion that is
not ZERO and not quite PRESERVE (since PRESERVE is defined as that
the guest will see what the host wrote post-encryption, but it
sounds like launch update is doing the encryption)
+ Or should launch update be called when that memory is shared? Will
launch update then also set that memory to private in guest_memfd?
>
> So maybe there should be an arch hook to check a whitelist of VM types
> that support KVM_MEMORY_ATTRIBUTE_PRIVATE when vm_memory_attributes=0,
> and if we decide to enable it for SNP as part of this series you could
> include the 1-2 patches needed there, or I could enable the SNP support
> separately as a small series and I guess that would then become a prereq
> for the SNP self-tests?
>
> Not sure if additional enablement is needed for TDX or not before
> KVM_MEMORY_ATTRIBUTE_PRIVATE would be advertised, but similar
> considerations there.
>
> -Mike
>
>> #endif
>> default:
>> break;
>>
>> --
>> 2.53.0.1018.g2bb0e51243-goog
>>
