> > @@ -4015,6 +4042,12 @@ static int snp_handle_guest_req(struct vcpu_svm *svm, gpa_t req_gpa, gpa_t resp_
> >
> > mutex_lock(&sev->guest_req_mutex);
> >
> > + if (!__ratelimit(&sev->snp_guest_msg_rs)) {
> > + svm_vmgexit_no_action(svm, SNP_GUEST_ERR(SNP_GUEST_VMM_ERR_BUSY, 0));
> > + ret = 1;
> > + goto out_unlock;
>
> Can you (or anyone) explain what a well-behaved guest will do in in response to
> BUSY? And/or explain why KVM injecting an error into the guest is better than
> exiting to userspace.
Ah, I missed this question. The guest is meant to back off and try
again after waiting a bit.
This is the behavior added in
https://lore.kernel.org/all/20230214164638.1189804-2-dionnaglaze@xxxxxxxxxx/
If KVM returns to userspace with an exit type that the guest request
was throttled, then
what is user space supposed to do with that? It could wait a bit
before trying KVM_RUN
again, but with the enlightened method, the guest could at least work
on other kernel
tasks while it waits for its turn to get an attestation report.
Perhaps this is me not understanding the preferred KVM way of doing things.
--
-Dionna Glaze, PhD, CISSP, CCSP (she/her)
