Michael Roth <[email protected]> writes: Thank you for your patches!
> > [...snip...] > >> >> I also did some minor updates (prefixed with a "[squash]" tag) to advertise >> the KVM_SET_MEMORY_ATTRIBUTES2_PRESERVED flag so it can be used by > > Though I'm not sure how we deal with it if SNP/TDX at some point become > capable of using the PRESERVED flag *after* populate... but maybe that's > too unlikely to worry about? If we wanted to address it though, we could > have both PRESERVED and PRESERVED_BEFORE_LAUNCH so they can be > enumerated separately from the start. > Not sure how likely it is, but if SNP and TDX can honor PRESERVE semantics after populate, I think we could implement support under a new flag like CIPHER. CIPHER can then be used to mean "do the encryption or decryption", and for platforms not supporting encryption, they'd stick with PRESERVE? Should we redefine the semantics of PRESERVE to be "ensure that memory contents don't change while guest_memfd tracking is being updated" and avoid making a commitment on how the guest should read the memory? The above update would be aligned with ZERO not being allowed for conversions to private (because KVM/guest_memfd does not make guarantees about the contract between the host and guest. This way, all of those (ZERO, PRESERVE) will focus on KVM's interface with the host. This lines up for SW_PROTECTED_VMs too, since reading memory that didn't change in the guest is the contract between SW_PROTECTED_VMs and the host. >> userspace for SNP/TDX in the kvm_gmem_populate() path as agreed upon >> during PUCK. >> >> >> [...snip...] >>
