| Message ID | 20200320102643.15516-3-ldufour@linux.ibm.com |
|---|---|
| State | Accepted |
| Headers | show |
| Series | Fix SVM hang at startup | expand |
On Fri, Mar 20, 2020 at 11:26:43AM +0100, Laurent Dufour wrote: > When the call to UV_REGISTER_MEM_SLOT is failing, for instance because > there is not enough free secured memory, the Hypervisor (HV) has to call > UV_RETURN to report the error to the Ultravisor (UV). Then the UV will call > H_SVM_INIT_ABORT to abort the securing phase and go back to the calling VM. > > If the kvm->arch.secure_guest is not set, in the return path rfid is called > but there is no valid context to get back to the SVM since the Hcall has > been routed by the Ultravisor. > > Move the setting of kvm->arch.secure_guest earlier in > kvmppc_h_svm_init_start() so in the return path, UV_RETURN will be called > instead of rfid. > > Cc: Bharata B Rao <bharata@linux.ibm.com> > Cc: Paul Mackerras <paulus@ozlabs.org> > Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org> > Cc: Michael Ellerman <mpe@ellerman.id.au> > Signed-off-by: Laurent Dufour <ldufour@linux.ibm.com> > --- > arch/powerpc/kvm/book3s_hv_uvmem.c | 3 ++- > 1 file changed, 2 insertions(+), 1 deletion(-) > > diff --git a/arch/powerpc/kvm/book3s_hv_uvmem.c b/arch/powerpc/kvm/book3s_hv_uvmem.c > index 79b1202b1c62..68dff151315c 100644 > --- a/arch/powerpc/kvm/book3s_hv_uvmem.c > +++ b/arch/powerpc/kvm/book3s_hv_uvmem.c > @@ -209,6 +209,8 @@ unsigned long kvmppc_h_svm_init_start(struct kvm *kvm) > int ret = H_SUCCESS; > int srcu_idx; > > + kvm->arch.secure_guest = KVMPPC_SECURE_INIT_START; > + > if (!kvmppc_uvmem_bitmap) > return H_UNSUPPORTED; > > @@ -233,7 +235,6 @@ unsigned long kvmppc_h_svm_init_start(struct kvm *kvm) > goto out; > } > } > - kvm->arch.secure_guest |= KVMPPC_SECURE_INIT_START; There is an assumption that memory slots would have been registered with UV if KVMPPC_SECURE_INIT_START has been done. KVM_PPC_SVM_OFF ioctl will skip unregistration and other steps during reboot if KVMPPC_SECURE_INIT_START hasn't been done. Have you checked if that path isn't affected by this change? Regards, Bharata.
Le 20/03/2020 à 12:24, Bharata B Rao a écrit : > On Fri, Mar 20, 2020 at 11:26:43AM +0100, Laurent Dufour wrote: >> When the call to UV_REGISTER_MEM_SLOT is failing, for instance because >> there is not enough free secured memory, the Hypervisor (HV) has to call >> UV_RETURN to report the error to the Ultravisor (UV). Then the UV will call >> H_SVM_INIT_ABORT to abort the securing phase and go back to the calling VM. >> >> If the kvm->arch.secure_guest is not set, in the return path rfid is called >> but there is no valid context to get back to the SVM since the Hcall has >> been routed by the Ultravisor. >> >> Move the setting of kvm->arch.secure_guest earlier in >> kvmppc_h_svm_init_start() so in the return path, UV_RETURN will be called >> instead of rfid. >> >> Cc: Bharata B Rao <bharata@linux.ibm.com> >> Cc: Paul Mackerras <paulus@ozlabs.org> >> Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org> >> Cc: Michael Ellerman <mpe@ellerman.id.au> >> Signed-off-by: Laurent Dufour <ldufour@linux.ibm.com> >> --- >> arch/powerpc/kvm/book3s_hv_uvmem.c | 3 ++- >> 1 file changed, 2 insertions(+), 1 deletion(-) >> >> diff --git a/arch/powerpc/kvm/book3s_hv_uvmem.c b/arch/powerpc/kvm/book3s_hv_uvmem.c >> index 79b1202b1c62..68dff151315c 100644 >> --- a/arch/powerpc/kvm/book3s_hv_uvmem.c >> +++ b/arch/powerpc/kvm/book3s_hv_uvmem.c >> @@ -209,6 +209,8 @@ unsigned long kvmppc_h_svm_init_start(struct kvm *kvm) >> int ret = H_SUCCESS; >> int srcu_idx; >> >> + kvm->arch.secure_guest = KVMPPC_SECURE_INIT_START; >> + >> if (!kvmppc_uvmem_bitmap) >> return H_UNSUPPORTED; >> >> @@ -233,7 +235,6 @@ unsigned long kvmppc_h_svm_init_start(struct kvm *kvm) >> goto out; >> } >> } >> - kvm->arch.secure_guest |= KVMPPC_SECURE_INIT_START; > > There is an assumption that memory slots would have been registered with UV > if KVMPPC_SECURE_INIT_START has been done. KVM_PPC_SVM_OFF ioctl will skip > unregistration and other steps during reboot if KVMPPC_SECURE_INIT_START > hasn't been done. > > Have you checked if that path isn't affected by this change? I checked that and didn't find any issue there. My only concern was that block: kvm_for_each_vcpu(i, vcpu, kvm) { spin_lock(&vcpu->arch.vpa_update_lock); unpin_vpa_reset(kvm, &vcpu->arch.dtl); unpin_vpa_reset(kvm, &vcpu->arch.slb_shadow); unpin_vpa_reset(kvm, &vcpu->arch.vpa); spin_unlock(&vcpu->arch.vpa_update_lock); } But that seems to be safe. However I'm not a familiar with the KVM's code, do you think an additional KVMPPC_SECURE_INIT_* value needed here? Thanks, Laurent.
On Fri, Mar 20, 2020 at 11:26:43AM +0100, Laurent Dufour wrote: > When the call to UV_REGISTER_MEM_SLOT is failing, for instance because > there is not enough free secured memory, the Hypervisor (HV) has to call secure memory, > UV_RETURN to report the error to the Ultravisor (UV). Then the UV will call > H_SVM_INIT_ABORT to abort the securing phase and go back to the calling VM. > > If the kvm->arch.secure_guest is not set, in the return path rfid is called > but there is no valid context to get back to the SVM since the Hcall has > been routed by the Ultravisor. > > Move the setting of kvm->arch.secure_guest earlier in > kvmppc_h_svm_init_start() so in the return path, UV_RETURN will be called > instead of rfid. > > Cc: Bharata B Rao <bharata@linux.ibm.com> > Cc: Paul Mackerras <paulus@ozlabs.org> > Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org> > Cc: Michael Ellerman <mpe@ellerman.id.au> > Signed-off-by: Laurent Dufour <ldufour@linux.ibm.com> Reviewed-by: Ram Pai <linuxram@us.ibm.com>
On Fri, Mar 20, 2020 at 03:36:05PM +0100, Laurent Dufour wrote: > Le 20/03/2020 à 12:24, Bharata B Rao a écrit : > > On Fri, Mar 20, 2020 at 11:26:43AM +0100, Laurent Dufour wrote: > > > When the call to UV_REGISTER_MEM_SLOT is failing, for instance because > > > there is not enough free secured memory, the Hypervisor (HV) has to call > > > UV_RETURN to report the error to the Ultravisor (UV). Then the UV will call > > > H_SVM_INIT_ABORT to abort the securing phase and go back to the calling VM. > > > > > > If the kvm->arch.secure_guest is not set, in the return path rfid is called > > > but there is no valid context to get back to the SVM since the Hcall has > > > been routed by the Ultravisor. > > > > > > Move the setting of kvm->arch.secure_guest earlier in > > > kvmppc_h_svm_init_start() so in the return path, UV_RETURN will be called > > > instead of rfid. > > > > > > Cc: Bharata B Rao <bharata@linux.ibm.com> > > > Cc: Paul Mackerras <paulus@ozlabs.org> > > > Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org> > > > Cc: Michael Ellerman <mpe@ellerman.id.au> > > > Signed-off-by: Laurent Dufour <ldufour@linux.ibm.com> > > > --- > > > arch/powerpc/kvm/book3s_hv_uvmem.c | 3 ++- > > > 1 file changed, 2 insertions(+), 1 deletion(-) > > > > > > diff --git a/arch/powerpc/kvm/book3s_hv_uvmem.c b/arch/powerpc/kvm/book3s_hv_uvmem.c > > > index 79b1202b1c62..68dff151315c 100644 > > > --- a/arch/powerpc/kvm/book3s_hv_uvmem.c > > > +++ b/arch/powerpc/kvm/book3s_hv_uvmem.c > > > @@ -209,6 +209,8 @@ unsigned long kvmppc_h_svm_init_start(struct kvm *kvm) > > > int ret = H_SUCCESS; > > > int srcu_idx; > > > + kvm->arch.secure_guest = KVMPPC_SECURE_INIT_START; > > > + > > > if (!kvmppc_uvmem_bitmap) > > > return H_UNSUPPORTED; > > > @@ -233,7 +235,6 @@ unsigned long kvmppc_h_svm_init_start(struct kvm *kvm) > > > goto out; > > > } > > > } > > > - kvm->arch.secure_guest |= KVMPPC_SECURE_INIT_START; > > > > There is an assumption that memory slots would have been registered with UV > > if KVMPPC_SECURE_INIT_START has been done. KVM_PPC_SVM_OFF ioctl will skip > > unregistration and other steps during reboot if KVMPPC_SECURE_INIT_START > > hasn't been done. > > > > Have you checked if that path isn't affected by this change? > > I checked that and didn't find any issue there. > > My only concern was that block: > kvm_for_each_vcpu(i, vcpu, kvm) { > spin_lock(&vcpu->arch.vpa_update_lock); > unpin_vpa_reset(kvm, &vcpu->arch.dtl); > unpin_vpa_reset(kvm, &vcpu->arch.slb_shadow); > unpin_vpa_reset(kvm, &vcpu->arch.vpa); > spin_unlock(&vcpu->arch.vpa_update_lock); > } > > But that seems to be safe. Yes, looks like. > > However I'm not a familiar with the KVM's code, do you think an additional > KVMPPC_SECURE_INIT_* value needed here? May be not as long as UV can handle the unexpected uv_unregister_mem_slot() calls, we are good. Regards, Bharata.
Laurent Dufour <ldufour@linux.ibm.com> writes: > When the call to UV_REGISTER_MEM_SLOT is failing, for instance because > there is not enough free secured memory, the Hypervisor (HV) has to call > UV_RETURN to report the error to the Ultravisor (UV). Then the UV will call > H_SVM_INIT_ABORT to abort the securing phase and go back to the calling VM. > > If the kvm->arch.secure_guest is not set, in the return path rfid is called > but there is no valid context to get back to the SVM since the Hcall has > been routed by the Ultravisor. > > Move the setting of kvm->arch.secure_guest earlier in > kvmppc_h_svm_init_start() so in the return path, UV_RETURN will be called > instead of rfid. > > Cc: Bharata B Rao <bharata@linux.ibm.com> > Cc: Paul Mackerras <paulus@ozlabs.org> > Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org> > Cc: Michael Ellerman <mpe@ellerman.id.au> > Signed-off-by: Laurent Dufour <ldufour@linux.ibm.com> > --- I tested this along with the code that rejects the secure transition when it is not enabled in KVM. I have also forced a KVM_PPC_SVM_OFF (via system_reset) right after setting kvm->arch.secure_guest and nothing bad happened. Tested-by: Fabiano Rosas <farosas@linux.ibm.com> > arch/powerpc/kvm/book3s_hv_uvmem.c | 3 ++- > 1 file changed, 2 insertions(+), 1 deletion(-) > > diff --git a/arch/powerpc/kvm/book3s_hv_uvmem.c b/arch/powerpc/kvm/book3s_hv_uvmem.c > index 79b1202b1c62..68dff151315c 100644 > --- a/arch/powerpc/kvm/book3s_hv_uvmem.c > +++ b/arch/powerpc/kvm/book3s_hv_uvmem.c > @@ -209,6 +209,8 @@ unsigned long kvmppc_h_svm_init_start(struct kvm *kvm) > int ret = H_SUCCESS; > int srcu_idx; > > + kvm->arch.secure_guest = KVMPPC_SECURE_INIT_START; > + > if (!kvmppc_uvmem_bitmap) > return H_UNSUPPORTED; > > @@ -233,7 +235,6 @@ unsigned long kvmppc_h_svm_init_start(struct kvm *kvm) > goto out; > } > } > - kvm->arch.secure_guest |= KVMPPC_SECURE_INIT_START; > out: > srcu_read_unlock(&kvm->srcu, srcu_idx); > return ret;
diff --git a/arch/powerpc/kvm/book3s_hv_uvmem.c b/arch/powerpc/kvm/book3s_hv_uvmem.c index 79b1202b1c62..68dff151315c 100644 --- a/arch/powerpc/kvm/book3s_hv_uvmem.c +++ b/arch/powerpc/kvm/book3s_hv_uvmem.c @@ -209,6 +209,8 @@ unsigned long kvmppc_h_svm_init_start(struct kvm *kvm) int ret = H_SUCCESS; int srcu_idx; + kvm->arch.secure_guest = KVMPPC_SECURE_INIT_START; + if (!kvmppc_uvmem_bitmap) return H_UNSUPPORTED; @@ -233,7 +235,6 @@ unsigned long kvmppc_h_svm_init_start(struct kvm *kvm) goto out; } } - kvm->arch.secure_guest |= KVMPPC_SECURE_INIT_START; out: srcu_read_unlock(&kvm->srcu, srcu_idx); return ret;
When the call to UV_REGISTER_MEM_SLOT is failing, for instance because there is not enough free secured memory, the Hypervisor (HV) has to call UV_RETURN to report the error to the Ultravisor (UV). Then the UV will call H_SVM_INIT_ABORT to abort the securing phase and go back to the calling VM. If the kvm->arch.secure_guest is not set, in the return path rfid is called but there is no valid context to get back to the SVM since the Hcall has been routed by the Ultravisor. Move the setting of kvm->arch.secure_guest earlier in kvmppc_h_svm_init_start() so in the return path, UV_RETURN will be called instead of rfid. Cc: Bharata B Rao <bharata@linux.ibm.com> Cc: Paul Mackerras <paulus@ozlabs.org> Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org> Cc: Michael Ellerman <mpe@ellerman.id.au> Signed-off-by: Laurent Dufour <ldufour@linux.ibm.com> --- arch/powerpc/kvm/book3s_hv_uvmem.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-)