| Message ID | 20230119213426.379312-3-dionnaglaze@google.com (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
| Series | kvm: sev: Add SNP guest request throttling | expand |
On 1/19/23 15:34, Dionna Glaze wrote: Since you're building on SNP hypervisor patches, please keep @Ashish on direct copy. > The ccp driver can be overloaded even with 1 HZ throttling. The return > value of -EBUSY means that there is no firmware error to report back to > user space, so the guest VM would see this as exitinfo2 = 0. The false > success can trick the guest to update its the message sequence number > when it shouldn't have. > > Instead, when ccp returns -EBUSY, that is reported to userspace as the > throttling return value. Except the CCP driver doesn't return -EBUSY because it is overloaded. It will simply try to acquire the mutex and continue once it has it. There are a couple of places that return -EBUSY in the driver for other reasons, as well as other -E* values. It looks like these need to be handled properly by the SNP hypervisor patches so that a "success" isn't reported back. So this patch isn't necessary, but any -E* return value without having actually called the firmware needs to be handled properly. @Ashish, please work with Dionna on this. Thanks, Tom > > Cc: Thomas Lendacky <Thomas.Lendacky@amd.com> > Cc: Paolo Bonzini <pbonzini@redhat.com> > Cc: Joerg Roedel <jroedel@suse.de> > Cc: Peter Gonda <pgonda@google.com> > Cc: Borislav Petkov <bp@alien8.de> > > Signed-off-by: Dionna Glaze <dionnaglaze@google.com> > --- > arch/x86/kvm/svm/sev.c | 18 ++++++++++++++++-- > 1 file changed, 16 insertions(+), 2 deletions(-) > > diff --git a/arch/x86/kvm/svm/sev.c b/arch/x86/kvm/svm/sev.c > index cd9372ce6fc2..7da1cc300d7b 100644 > --- a/arch/x86/kvm/svm/sev.c > +++ b/arch/x86/kvm/svm/sev.c > @@ -3642,7 +3642,14 @@ static void snp_handle_guest_request(struct vcpu_svm *svm, gpa_t req_gpa, gpa_t > goto unlock; > > rc = sev_issue_cmd(kvm, SEV_CMD_SNP_GUEST_REQUEST, &data, &err); > - if (rc) > + > + /* > + * The ccp driver can return -EBUSY if the PSP is overloaded, so signal > + * the request has been throttled. > + */ > + if (rc == -EBUSY) > + rc = SNP_GUEST_REQ_THROTTLED; > + else if (rc) > /* use the firmware error code */ > rc = err; > > @@ -3713,7 +3720,14 @@ static void snp_handle_ext_guest_request(struct vcpu_svm *svm, gpa_t req_gpa, gp > if (sev->snp_certs_len) > data_npages = sev->snp_certs_len >> PAGE_SHIFT; > > - if (rc) { > + /* > + * The ccp driver can return -EBUSY if the PSP is overloaded, so signal > + * the request has been throttled. > + */ > + if (rc == -EBUSY) { > + rc = SNP_GUEST_REQ_THROTTLED; > + goto cleanup; > + } else if (rc) { > /* > * If buffer length is small then return the expected > * length in rbx.
diff --git a/arch/x86/kvm/svm/sev.c b/arch/x86/kvm/svm/sev.c index cd9372ce6fc2..7da1cc300d7b 100644 --- a/arch/x86/kvm/svm/sev.c +++ b/arch/x86/kvm/svm/sev.c @@ -3642,7 +3642,14 @@ static void snp_handle_guest_request(struct vcpu_svm *svm, gpa_t req_gpa, gpa_t goto unlock; rc = sev_issue_cmd(kvm, SEV_CMD_SNP_GUEST_REQUEST, &data, &err); - if (rc) + + /* + * The ccp driver can return -EBUSY if the PSP is overloaded, so signal + * the request has been throttled. + */ + if (rc == -EBUSY) + rc = SNP_GUEST_REQ_THROTTLED; + else if (rc) /* use the firmware error code */ rc = err; @@ -3713,7 +3720,14 @@ static void snp_handle_ext_guest_request(struct vcpu_svm *svm, gpa_t req_gpa, gp if (sev->snp_certs_len) data_npages = sev->snp_certs_len >> PAGE_SHIFT; - if (rc) { + /* + * The ccp driver can return -EBUSY if the PSP is overloaded, so signal + * the request has been throttled. + */ + if (rc == -EBUSY) { + rc = SNP_GUEST_REQ_THROTTLED; + goto cleanup; + } else if (rc) { /* * If buffer length is small then return the expected * length in rbx.
The ccp driver can be overloaded even with 1 HZ throttling. The return value of -EBUSY means that there is no firmware error to report back to user space, so the guest VM would see this as exitinfo2 = 0. The false success can trick the guest to update its the message sequence number when it shouldn't have. Instead, when ccp returns -EBUSY, that is reported to userspace as the throttling return value. Cc: Thomas Lendacky <Thomas.Lendacky@amd.com> Cc: Paolo Bonzini <pbonzini@redhat.com> Cc: Joerg Roedel <jroedel@suse.de> Cc: Peter Gonda <pgonda@google.com> Cc: Borislav Petkov <bp@alien8.de> Signed-off-by: Dionna Glaze <dionnaglaze@google.com> --- arch/x86/kvm/svm/sev.c | 18 ++++++++++++++++-- 1 file changed, 16 insertions(+), 2 deletions(-)