Hello Paolo, On Thu, Mar 19, 2020 at 02:05:21PM +0100, Paolo Bonzini wrote: > On 17/02/20 20:49, Ashish Kalra wrote: > >> Also, you're making guest-side and host-side changes. What ensures > >> that you don't try to migrate a guest that doesn't support the > >> hypercall for encryption state tracking? > > This is a good question and it is still an open-ended question. There > > are two possibilities here: guest does not have any unencrypted pages > > (for e.g booting 32-bit) and so it does not make any hypercalls, and > > the other possibility is that the guest does not have support for > > the newer hypercall. > > > > In the first case, all the guest pages are then assumed to be > > encrypted and live migration happens as such. > > > > For the second case, we have been discussing this internally, > > and one option is to extend the KVM capabilites/feature bits to check for this ? > > You could extend the hypercall to completely block live migration (e.g. > a0=a1=~0, a2=0 to unblock or 1 to block). The KVM_GET_PAGE_ENC_BITMAP > ioctl can also return the blocked/unblocked state. > Currently i have added a new KVM para feature "KVM_FEATURE_SEV_LIVE_MIGRATION" to indicate host support for the SEV live migration feature and a custom KVM MSR "MSR_KVM_SEV_LIVE_MIG_EN" for the guest to enable SEV live migration. The MSR also has other flags for future SEV live migration extensions. Thanks, Ashish
