Re: [PATCH 2/3 V7] KVM, SEV: Add support for SEV-ES intra host migration

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Thu, Sep 02, 2021, Peter Gonda wrote:
> diff --git a/arch/x86/kvm/svm/sev.c b/arch/x86/kvm/svm/sev.c
> index 8db666a362d4..fac21a82e4de 100644
> --- a/arch/x86/kvm/svm/sev.c
> +++ b/arch/x86/kvm/svm/sev.c
> @@ -1545,6 +1545,59 @@ static void migrate_info_from(struct kvm_sev_info *dst,
>  	list_replace_init(&src->regions_list, &dst->regions_list);
>  }
>  
> +static int migrate_vmsa_from(struct kvm *dst, struct kvm *src)
> +{
> +	int i, num_vcpus;
> +	struct kvm_vcpu *dst_vcpu, *src_vcpu;
> +	struct vcpu_svm *dst_svm, *src_svm;
> +
> +	num_vcpus = atomic_read(&dst->online_vcpus);
> +	if (num_vcpus != atomic_read(&src->online_vcpus)) {
> +		pr_warn_ratelimited(
> +			"Source and target VMs must have same number of vCPUs.\n");

Same comments about not logging the why.

> +		return -EINVAL;
> +	}
> +
> +	for (i = 0; i < num_vcpus; ++i) 
> +		src_vcpu = src->vcpus[i];

This can be:

	kvm_for_each_vcpu(i, src_vcpu, src) {
		if (!src_vcpu->arch.guest_state_protected)
			return -EINVAL;

	}
> +		if (!src_vcpu->arch.guest_state_protected) {
> +			pr_warn_ratelimited(
> +				"Source ES VM vCPUs must have protected state.\n");
> +			return -EINVAL;
> +		}
> +	}
> +
> +	for (i = 0; i < num_vcpus; ++i) {

And again here,

	kvm_for_each_vcpu(i, src_vcpu, src) {
		src_svm = to_svm(src_vcpu);

> +		src_vcpu = src->vcpus[i];
> +		src_svm = to_svm(src_vcpu);
> +		dst_vcpu = dst->vcpus[i];

Probably a good idea to use kvm_get_vcpu(), even though dst->lock is held.  If
nothing else, using kvm_get_vcpu() may save some merge pain as there's a proposal
to switch vcpus to an xarray.

> +		dst_svm = to_svm(dst_vcpu);
> +
> +		/*
> +		 * Copy VMSA and GHCB fields from the source to the destination.
> +		 * Clear them on the source to prevent the VM running and

As brought up in the prior patch, clearing the fields might ensure future KVM_RUNs
fail, but it doesn't prevent the VM from running _now_.  And with vcpu->mutext
held, I think a more appropriate comment would be:

		/*
		 * Transfer VMSA and GHCB state to the destination.  Nullify and
		 * clear source fields as appropriate, the state now belongs to
		 * the destination.
		 */

> +		 * changing the state of the VMSA/GHCB unexpectedly.
> +		 */
> +		dst_vcpu->vcpu_id = src_vcpu->vcpu_id;
> +		dst_svm->vmsa = src_svm->vmsa;
> +		src_svm->vmsa = NULL;
> +		dst_svm->ghcb = src_svm->ghcb;
> +		src_svm->ghcb = NULL;
> +		dst_svm->vmcb->control.ghcb_gpa =
> +				src_svm->vmcb->control.ghcb_gpa;

Let this poke out, an 83 char line isn't the end of the world, and not having
the interrupt makes the code more readable overall.

> +		src_svm->vmcb->control.ghcb_gpa = 0;

Nit, '0' isn't an invalid GPA.  The reset value would be more appropriate, though
I would just leave this alone.

> +		dst_svm->ghcb_sa = src_svm->ghcb_sa;
> +		src_svm->ghcb_sa = NULL;
> +		dst_svm->ghcb_sa_len = src_svm->ghcb_sa_len;
> +		src_svm->ghcb_sa_len = 0;
> +		dst_svm->ghcb_sa_sync = src_svm->ghcb_sa_sync;
> +		src_svm->ghcb_sa_sync = false;
> +		dst_svm->ghcb_sa_free = src_svm->ghcb_sa_free;
> +		src_svm->ghcb_sa_free = false;
> +	}
> +	return 0;
> +}



[Index of Archives]     [KVM ARM]     [KVM ia64]     [KVM ppc]     [Virtualization Tools]     [Spice Development]     [Libvirt]     [Libvirt Users]     [Linux USB Devel]     [Linux Audio Users]     [Yosemite Questions]     [Linux Kernel]     [Linux SCSI]     [XFree86]

  Powered by Linux