Ackerley Tng <[email protected]> writes: > > [...snip...] >
>> 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). > > > [...snip...] > > > 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? > Update after today's guest_memfd biweekly: guest_memfd's populate will first check that the memory is shared, then also set the memory to private after the populate. KVM must not make assumptions about any memory that is private, so it should actually only be operating on memory that is shared. This is aligned with pre-in-place-conversion, since before this series, there was no way to populate from private memory anyway. >> >> [...snip...] >>
