Message-ID: <YYRZq+Zt52FSyjVW@google.com>
Date:   Thu, 4 Nov 2021 22:07:39 +0000
From:   Sean Christopherson <seanjc@...gle.com>
To:     Peter Gonda <pgonda@...gle.com>
Cc:     kvm@...r.kernel.org, Marc Orr <marcorr@...gle.com>,
        Paolo Bonzini <pbonzini@...hat.com>,
        David Rientjes <rientjes@...gle.com>,
        "Dr . David Alan Gilbert" <dgilbert@...hat.com>,
        Brijesh Singh <brijesh.singh@....com>,
        Tom Lendacky <thomas.lendacky@....com>,
        Vitaly Kuznetsov <vkuznets@...hat.com>,
        Wanpeng Li <wanpengli@...cent.com>,
        Jim Mattson <jmattson@...gle.com>,
        Joerg Roedel <joro@...tes.org>,
        Thomas Gleixner <tglx@...utronix.de>,
        Ingo Molnar <mingo@...hat.com>, Borislav Petkov <bp@...en8.de>,
        "H. Peter Anvin" <hpa@...or.com>, linux-kernel@...r.kernel.org
Subject: Re: [PATCH V11 2/5] KVM: SEV: Add support for SEV intra host
 migration

Paolo and anyone else, any thoughts before I lead Peter on an even longer wild
goose chase?

On Thu, Oct 21, 2021, Peter Gonda wrote:
> @@ -6706,6 +6706,21 @@ MAP_SHARED mmap will result in an -EINVAL return.
>  When enabled the VMM may make use of the ``KVM_ARM_MTE_COPY_TAGS`` ioctl to
>  perform a bulk copy of tags to/from the guest.
>  
> +7.29 KVM_CAP_VM_MIGRATE_PROTECTED_VM_FROM
> +-------------------------------------
> +
> +Architectures: x86 SEV enabled

I'd drop the "SEV enabled" part.  In a way, it's technically a lie for this one
patch since an SEV-ES VM is also an SEV VM, but doesn't support this capability.
And AFAICT no other ioctl()/capability provides this level of granularity.

> +Type: vm
> +Parameters: args[0] is the fd of the source vm
> +Returns: 0 on success
> +
> +This capability enables userspace to migrate the encryption context from the VM
> +indicated by the fd to the VM this is called on.
> +
> +This is intended to support intra-host migration of VMs between userspace VMMs.
> +in-guest workloads scheduled by the host. This allows for upgrading the VMM
> +process without interrupting the guest.
> +

...

> +static void sev_unlock_vcpus_for_migration(struct kvm *kvm)
> +{
> +	struct kvm_vcpu *vcpu;
> +	int i;
> +
> +	kvm_for_each_vcpu(i, vcpu, kvm) {

Braces not needed.

> +		mutex_unlock(&vcpu->mutex);
> +	}
> +}
> +
> +static void sev_migrate_from(struct kvm_sev_info *dst,
> +			      struct kvm_sev_info *src)
> +{
> +	dst->active = true;
> +	dst->asid = src->asid;
> +	dst->misc_cg = src->misc_cg;

Ah, this is not correct.  If @dst is in a different cgroup, then @dst needs to
be charged and @src needs to be uncharged.

That would also provide a good opportunity to more tightly couple ->asid and
->misc_cg in the form of a helper.  Looking at the code, there's an invariant
that misc_cg is NULL if an ASID is not assigned.  I.e. these three lines belong
in a helper, irrespective of this code.

	misc_cg_uncharge(type, sev->misc_cg, 1);
	put_misc_cg(sev->misc_cg);
	sev->misc_cg = NULL;

> +	dst->handle = src->handle;
> +	dst->pages_locked = src->pages_locked;
> +
> +	src->asid = 0;
> +	src->active = false;
> +	src->handle = 0;
> +	src->pages_locked = 0;
> +	src->misc_cg = NULL;
> +	INIT_LIST_HEAD(&dst->regions_list);
> +	list_replace_init(&src->regions_list, &dst->regions_list);
> +}
> +
> +int svm_vm_migrate_from(struct kvm *kvm, unsigned int source_fd)
> +{
> +	struct kvm_sev_info *dst_sev = &to_kvm_svm(kvm)->sev_info;
> +	struct file *source_kvm_file;
> +	struct kvm *source_kvm;
> +	struct kvm_vcpu *vcpu;
> +	int i, ret;
> +
> +	ret = sev_lock_for_migration(kvm);
> +	if (ret)
> +		return ret;
> +
> +	if (sev_guest(kvm)) {
> +		ret = -EINVAL;
> +		goto out_unlock;
> +	}
> +
> +	source_kvm_file = fget(source_fd);
> +	if (!file_is_kvm(source_kvm_file)) {
> +		ret = -EBADF;
> +		goto out_fput;
> +	}
> +
> +	source_kvm = source_kvm_file->private_data;
> +	ret = sev_lock_for_migration(source_kvm);
> +	if (ret)
> +		goto out_fput;
> +
> +	if (!sev_guest(source_kvm) || sev_es_guest(source_kvm)) {
> +		ret = -EINVAL;
> +		goto out_source;
> +	}
> +	ret = sev_lock_vcpus_for_migration(kvm);
> +	if (ret)
> +		goto out_dst_vcpu;
> +	ret = sev_lock_vcpus_for_migration(source_kvm);
> +	if (ret)
> +		goto out_source_vcpu;
> +
> +	sev_migrate_from(dst_sev, &to_kvm_svm(source_kvm)->sev_info);
> +	kvm_for_each_vcpu(i, vcpu, source_kvm) {

Braces not needed.

> +		kvm_vcpu_reset(vcpu, /* init_event= */ false);

Phooey.  I made this suggestion, but in hindsight, it's a bad suggestion as KVM
doesn't currently have a true RESET path; there are quite a few blobs of code
that assume the vCPU has never been run if init_event=false.

And to go through kvm_vcpu_reset(), the vcpu needs to be loaded, not just locked.
It won't fail as hard as VMX, where KVM would write the wrong VMCS, but odds are
good something will eventually go sideways.

Aha!  An idea.  Marking the VM bugged doesn't work because "we need to keep using
the  source VM even after the state is transfered"[*], but the core idea is sound,
it just needs to add a different flag to more precisely prevent kvm_vcpu_ioctl().

If we rename KVM_REQ_VM_BUGGED=>KVM_REQ_VM_DEAD in a prep patch (see below), then
this patch can add something here (can't think of a good name)

	source_kvm->??? = true;
	kvm_make_all_cpus_request(kvm, KVM_REQ_VM_DEAD);

and then check it in kvm_vcpu_ioctl()

	struct kvm *kvm = vcpu->kvm;

	if (kvm->mm != current->mm || kvm->vm_bugged || kvm->???)
		return -EIO;

That way the source vCPUs don't need to be locked and all vCPU ioctls() are
blocked, which I think is ideal since the vCPUs are in a frankenstate and really
should just die.

Maybe we can call the flag "zombie", or "mostly_dead" :-)

diff --git a/arch/x86/kvm/x86.c b/arch/x86/kvm/x86.c
index c80fa1d378c9..e3f49ca01f95 100644
--- a/arch/x86/kvm/x86.c
+++ b/arch/x86/kvm/x86.c
@@ -9423,7 +9423,7 @@ static int vcpu_enter_guest(struct kvm_vcpu *vcpu)
        }

        if (kvm_request_pending(vcpu)) {
-               if (kvm_check_request(KVM_REQ_VM_BUGGED, vcpu)) {
+               if (kvm_check_request(KVM_REQ_VM_DEAD, vcpu)) {
                        r = -EIO;
                        goto out;
                }
diff --git a/include/linux/kvm_host.h b/include/linux/kvm_host.h
index 0f18df7fe874..de8d25cef183 100644
--- a/include/linux/kvm_host.h
+++ b/include/linux/kvm_host.h
@@ -150,7 +150,7 @@ static inline bool is_error_page(struct page *page)
 #define KVM_REQ_MMU_RELOAD        (1 | KVM_REQUEST_WAIT | KVM_REQUEST_NO_WAKEUP)
 #define KVM_REQ_UNBLOCK           2
 #define KVM_REQ_UNHALT            3
-#define KVM_REQ_VM_BUGGED         (4 | KVM_REQUEST_WAIT | KVM_REQUEST_NO_WAKEUP)
+#define KVM_REQ_VM_DEAD                  (4 | KVM_REQUEST_WAIT | KVM_REQUEST_NO_WAKEUP)
 #define KVM_REQUEST_ARCH_BASE     8

 #define KVM_ARCH_REQ_FLAGS(nr, flags) ({ \
@@ -654,7 +654,7 @@ struct kvm {
 static inline void kvm_vm_bugged(struct kvm *kvm)
 {
        kvm->vm_bugged = true;
-       kvm_make_all_cpus_request(kvm, KVM_REQ_VM_BUGGED);
+       kvm_make_all_cpus_request(kvm, KVM_REQ_VM_DEAD);
 }

 #define KVM_BUG(cond, kvm, fmt...)


Back when I made this bad suggestion in v7, you said "we need to keep using the
source VM even after the state is transfered"[*].  What all do you need to do
after the migration?  I assume it's mostly memory related per-VM ioctls?


[*] https://lkml.kernel.org/r/CAMkAt6q3as414YMZco6UyCycY+jKbaYS5BUdC+U+8iWmBft3+A@mail.gmail.com

> +	}
> +	ret = 0;
> +
> +out_source_vcpu:
> +	sev_unlock_vcpus_for_migration(source_kvm);
> +
> +out_dst_vcpu:
> +	sev_unlock_vcpus_for_migration(kvm);
> +
> +out_source:
> +	sev_unlock_after_migration(source_kvm);
> +out_fput:
> +	if (source_kvm_file)
> +		fput(source_kvm_file);
> +out_unlock:
> +	sev_unlock_after_migration(kvm);
> +	return ret;
> +}
> +
>  int svm_mem_enc_op(struct kvm *kvm, void __user *argp)
>  {
>  	struct kvm_sev_cmd sev_cmd;
> diff --git a/arch/x86/kvm/svm/svm.c b/arch/x86/kvm/svm/svm.c
> index 68294491c23d..c2e25ae4757f 100644
> --- a/arch/x86/kvm/svm/svm.c
> +++ b/arch/x86/kvm/svm/svm.c
> @@ -4637,6 +4637,7 @@ static struct kvm_x86_ops svm_x86_ops __initdata = {
>  	.mem_enc_unreg_region = svm_unregister_enc_region,
>  
>  	.vm_copy_enc_context_from = svm_vm_copy_asid_from,
> +	.vm_migrate_protected_vm_from = svm_vm_migrate_from,
>  
>  	.can_emulate_instruction = svm_can_emulate_instruction,
>  
> diff --git a/arch/x86/kvm/svm/svm.h b/arch/x86/kvm/svm/svm.h
> index 6d8d762d208f..d7b44b37dfcf 100644
> --- a/arch/x86/kvm/svm/svm.h
> +++ b/arch/x86/kvm/svm/svm.h
> @@ -80,6 +80,7 @@ struct kvm_sev_info {
>  	u64 ap_jump_table;	/* SEV-ES AP Jump Table address */
>  	struct kvm *enc_context_owner; /* Owner of copied encryption context */
>  	struct misc_cg *misc_cg; /* For misc cgroup accounting */
> +	atomic_t migration_in_progress;
>  };
>  
>  struct kvm_svm {
> @@ -557,6 +558,7 @@ int svm_register_enc_region(struct kvm *kvm,
>  int svm_unregister_enc_region(struct kvm *kvm,
>  			      struct kvm_enc_region *range);
>  int svm_vm_copy_asid_from(struct kvm *kvm, unsigned int source_fd);
> +int svm_vm_migrate_from(struct kvm *kvm, unsigned int source_fd);
>  void pre_sev_run(struct vcpu_svm *svm, int cpu);
>  void __init sev_set_cpu_caps(void);
>  void __init sev_hardware_setup(void);
> diff --git a/arch/x86/kvm/x86.c b/arch/x86/kvm/x86.c
> index 0c8b5129effd..c80fa1d378c9 100644
> --- a/arch/x86/kvm/x86.c
> +++ b/arch/x86/kvm/x86.c
> @@ -5665,6 +5665,12 @@ int kvm_vm_ioctl_enable_cap(struct kvm *kvm,
>  		if (kvm_x86_ops.vm_copy_enc_context_from)
>  			r = kvm_x86_ops.vm_copy_enc_context_from(kvm, cap->args[0]);
>  		return r;
> +	case KVM_CAP_VM_MIGRATE_PROTECTED_VM_FROM:

I wonder... would it make sense to hedge and just call this KVM_CAP_VM_MIGRATE_VM_FROM?
I can't think of a use case where KVM would "need" to do this for a non-protected
VM, but I also don't see a huge naming problem if the "PROTECTED" is omitted.

> +		r = -EINVAL;
> +		if (kvm_x86_ops.vm_migrate_protected_vm_from)
> +			r = kvm_x86_ops.vm_migrate_protected_vm_from(
> +				kvm, cap->args[0]);

Either let that poke out and/or refactor to avoid the indentation.  E.g.

		r = -EINVAL;
		if (!kvm_x86_ops.vm_migrate_protected_vm_from)
			break;

		return kvm_x86_ops.vm_migrate_protected_vm_from(kvm, cap->args[0]);

		
> +		return r;
>  	case KVM_CAP_EXIT_HYPERCALL:
>  		if (cap->args[0] & ~KVM_EXIT_HYPERCALL_VALID_MASK) {
>  			r = -EINVAL;
> diff --git a/include/uapi/linux/kvm.h b/include/uapi/linux/kvm.h
> index a067410ebea5..77b292ed01c1 100644
> --- a/include/uapi/linux/kvm.h
> +++ b/include/uapi/linux/kvm.h
> @@ -1112,6 +1112,7 @@ struct kvm_ppc_resize_hpt {
>  #define KVM_CAP_BINARY_STATS_FD 203
>  #define KVM_CAP_EXIT_ON_EMULATION_FAILURE 204
>  #define KVM_CAP_ARM_MTE 205
> +#define KVM_CAP_VM_MIGRATE_PROTECTED_VM_FROM 206
>  
>  #ifdef KVM_CAP_IRQ_ROUTING
>  
> -- 
> 2.33.0.1079.g6e70778dc9-goog
> 

Powered by blists - more mailing lists