Hi Ackerley, <snip>
> > By default, KVM makes no guarantees about the in-memory values after memory > > is > > convert to/from shared/private. Optionally, userspace may instruct KVM to > > ensure the contents of memory are zeroed or preserved, e.g. to enable > > in-place > > sharing of data, or as an optimization to avoid having to re-zero memory > > when > > the trusted entity guarantees the memory will be zeroed after conversion. > > > > How about: > > or as an optimization to avoid having to re-zero memory when userspace > could have relied on the trusted entity to guarantee the memory will be > zeroed as part of the entire conversion process. > > > The behaviors supported by a given KVM instance can be queried via <cap>. > > If > > I started with some implementation and was questioning the value of a > CAP. It seems like there won't be anything dynamic about this? We can drop the CAP for now. Probing via the ioctl and handling -EOPNOTSUPP is entirely sufficient for the VMM to discover whether ZERO or PRESERVE are supported for a given architecture and conversion direction. > The userspace code can check what platform it is running on, and then > decide ZERO or PRESERVE based on the platform: > > If the VM is running on TDX, it would want to specify ZERO all the > time. If the VM were running on pKVM it would want to specify PRESERVE > if it wants to enable in-place sharing, and ZERO if it wants to zero the > memory. > > If someday TDX supports PRESERVE, then there's room for discovery of > which algorithm to choose when running the guest. Perhaps that's when > the CAP should be introduced? > > > the requested behavior is an unsupported, KVM will return -EOPNOTSUPP and > > reject the conversion request. Note! The "ZERO" request is only support > > for > > private to shared conversion! I think that this makes sensefor the UAPI. Returning -EOPNOTSUPP for shared-to-private ZERO conversions. For pKVM's specific use cases where the VMM requires a zeroed page to be injected into the guest's private space via attribute conversion, the VMM can simply `memset()` the shared memory to zero in userspace, and then invoke the ioctl with the `KVM_SET_MEMORY_ATTRIBUTES2_PRESERVE` flag. This completely offloads the UAPI from making guarantees on behalf of the trusted entity, while still satisfying pKVM's functional requirements. Cheers, /fuad
