> +
> + switch (request) {
> + case SVM_VMGEXIT_AP_CREATE_ON_INIT:
> + kick = false;
> + fallthrough;
> + case SVM_VMGEXIT_AP_CREATE:
> + if (!page_address_valid(vcpu, svm->vmcb->control.exit_info_2)) {
> + vcpu_unimpl(vcpu, "vmgexit: invalid AP VMSA address [%#llx] from guest\n",
> + svm->vmcb->control.exit_info_2);
> + ret = -EINVAL;
> + goto out;
> + }
> +
> + /*
> + * Malicious guest can RMPADJUST a large page into VMSA which
> + * will hit the SNP erratum where the CPU will incorrectly signal
> + * an RMP violation #PF if a hugepage collides with the RMP entry
> + * of VMSA page, reject the AP CREATE request if VMSA address from
> + * guest is 2M aligned.
> + */
> + if (IS_ALIGNED(svm->vmcb->control.exit_info_2, PMD_SIZE)) {
> + vcpu_unimpl(vcpu,
> + "vmgexit: AP VMSA address [%llx] from guest is unsafe as it is 2M aligned\n",
> + svm->vmcb->control.exit_info_2);
In this case and maybe the above case can we instead return an error
to the guest instead of a #GP?
I think Tom suggested: SW_EXITINFO1[31:0] to 2 (meaning there was an
error with the VMGEXIT request) and SW_EXITINFO2 to 5 (The NAE event
input was not valid (e.g., an invalid SW_EXITINFO1 value for the AP
Jump Table NAE event).
This way a non-malicious but buggy or naive guest gets a little more
information and a chance to retry the request?
> + ret = -EINVAL;
> + goto out;
> + }
> +
> + target_svm->sev_es.snp_vmsa_gpa = svm->vmcb->control.exit_info_2;
> + break;
> + case SVM_VMGEXIT_AP_DESTROY:
> + break;
> + default:
> + vcpu_unimpl(vcpu, "vmgexit: invalid AP creation request [%#x] from guest\n",
> + request);
> + ret = -EINVAL;
> + break;
> + }
> +
