From: Michael Roth <michael.roth@amd.com>
To: <kvm@vger.kernel.org>
Cc: <linux-coco@lists.linux.dev>, <linux-kernel@vger.kernel.org>,
<x86@kernel.org>, <pbonzini@redhat.com>, <seanjc@google.com>,
<jroedel@suse.de>, <thomas.lendacky@amd.com>, <pgonda@google.com>,
<ashish.kalra@amd.com>, <bp@alien8.de>, <pankaj.gupta@amd.com>,
<liam.merwick@oracle.com>, Brijesh Singh <brijesh.singh@amd.com>,
"Alexey Kardashevskiy" <aik@amd.com>
Subject: [PATCH v1-revised 1/5] KVM: SEV: Provide support for SNP_GUEST_REQUEST NAE event
Date: Fri, 21 Jun 2024 12:15:19 -0500 [thread overview]
Message-ID: <20240621171519.3180965-1-michael.roth@amd.com> (raw)
In-Reply-To: <20240621134041.3170480-2-michael.roth@amd.com>
From: Brijesh Singh <brijesh.singh@amd.com>
Version 2 of GHCB specification added support for the SNP Guest Request
Message NAE event. The event allows for an SEV-SNP guest to make
requests to the SEV-SNP firmware through hypervisor using the
SNP_GUEST_REQUEST API defined in the SEV-SNP firmware specification.
This is used by guests primarily to request attestation reports from
firmware. There are other request types are available as well, but the
specifics of what guest requests are being made are opaque to the
hypervisor, which only serves as a proxy for the guest requests and
firmware responses.
Implement handling for these events.
Signed-off-by: Brijesh Singh <brijesh.singh@amd.com>
Co-developed-by: Alexey Kardashevskiy <aik@amd.com>
Signed-off-by: Alexey Kardashevskiy <aik@amd.com>
Co-developed-by: Ashish Kalra <ashish.kalra@amd.com>
Signed-off-by: Ashish Kalra <ashish.kalra@amd.com>
Reviewed-by: Tom Lendacky <thomas.lendacky@amd.com>
[mdr: ensure FW command failures are indicated to guest, drop extended
request handling to be re-written as separate patch, massage commit]
Signed-off-by: Michael Roth <michael.roth@amd.com>
Message-ID: <20240501085210.2213060-19-michael.roth@amd.com>
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
---
arch/x86/kvm/svm/sev.c | 73 ++++++++++++++++++++++++++++++++++
include/uapi/linux/sev-guest.h | 9 +++++
2 files changed, 82 insertions(+)
diff --git a/arch/x86/kvm/svm/sev.c b/arch/x86/kvm/svm/sev.c
index df8818759698..d9921ea87a81 100644
--- a/arch/x86/kvm/svm/sev.c
+++ b/arch/x86/kvm/svm/sev.c
@@ -19,6 +19,7 @@
#include <linux/misc_cgroup.h>
#include <linux/processor.h>
#include <linux/trace_events.h>
+#include <uapi/linux/sev-guest.h>
#include <asm/pkru.h>
#include <asm/trapnr.h>
@@ -3321,6 +3322,10 @@ static int sev_es_validate_vmgexit(struct vcpu_svm *svm)
if (!sev_snp_guest(vcpu->kvm) || !kvm_ghcb_sw_scratch_is_valid(svm))
goto vmgexit_err;
break;
+ case SVM_VMGEXIT_GUEST_REQUEST:
+ if (!sev_snp_guest(vcpu->kvm))
+ goto vmgexit_err;
+ break;
default:
reason = GHCB_ERR_INVALID_EVENT;
goto vmgexit_err;
@@ -3939,6 +3944,71 @@ static int sev_snp_ap_creation(struct vcpu_svm *svm)
return ret;
}
+static int snp_handle_guest_req(struct vcpu_svm *svm, gpa_t req_gpa, gpa_t resp_gpa)
+{
+ struct sev_data_snp_guest_request data = {0};
+ struct kvm *kvm = svm->vcpu.kvm;
+ kvm_pfn_t req_pfn, resp_pfn;
+ sev_ret_code fw_err = 0;
+ int ret;
+
+ if (!sev_snp_guest(kvm) || !PAGE_ALIGNED(req_gpa) || !PAGE_ALIGNED(resp_gpa))
+ return -EINVAL;
+
+ req_pfn = gfn_to_pfn(kvm, gpa_to_gfn(req_gpa));
+ if (is_error_noslot_pfn(req_pfn))
+ return -EINVAL;
+
+ resp_pfn = gfn_to_pfn(kvm, gpa_to_gfn(resp_gpa));
+ if (is_error_noslot_pfn(resp_pfn)) {
+ ret = EINVAL;
+ goto release_req;
+ }
+
+ if (rmp_make_private(resp_pfn, 0, PG_LEVEL_4K, 0, true)) {
+ ret = -EINVAL;
+ kvm_release_pfn_clean(resp_pfn);
+ goto release_req;
+ }
+
+ data.gctx_paddr = __psp_pa(to_kvm_sev_info(kvm)->snp_context);
+ data.req_paddr = __sme_set(req_pfn << PAGE_SHIFT);
+ data.res_paddr = __sme_set(resp_pfn << PAGE_SHIFT);
+
+ /* Firmware failures are propagated on to guest. */
+ ret = sev_issue_cmd(kvm, SEV_CMD_SNP_GUEST_REQUEST, &data, &fw_err);
+ if (ret)
+ pr_debug("%s: guest request failed, ret %d fw_err %d",
+ __func__, ret, fw_err);
+
+ /*
+ * If reclaim fails then there's a good chance the guest will no longer
+ * be runnable so just let userspace terminate the guest. Don't try to
+ * release the resp_pfn page reference in that case since it is no
+ * longer usable for future allocations.
+ */
+ if (snp_page_reclaim(kvm, resp_pfn)) {
+ ret = -EIO;
+ goto release_req;
+ }
+
+ /*
+ * As per GHCB spec, firmware failures should be communicated back to
+ * the guest via SW_EXITINFO2 rather than be treated as immediately
+ * fatal.
+ */
+ ghcb_set_sw_exit_info_2(svm->sev_es.ghcb,
+ SNP_GUEST_ERR(ret ? SNP_GUEST_VMM_ERR_GENERIC : 0,
+ fw_err));
+
+ ret = 1; /* resume guest */
+ kvm_release_pfn_dirty(resp_pfn);
+
+release_req:
+ kvm_release_pfn_clean(req_pfn);
+ return ret;
+}
+
static int sev_handle_vmgexit_msr_protocol(struct vcpu_svm *svm)
{
struct vmcb_control_area *control = &svm->vmcb->control;
@@ -4213,6 +4283,9 @@ int sev_handle_vmgexit(struct kvm_vcpu *vcpu)
ret = 1;
break;
+ case SVM_VMGEXIT_GUEST_REQUEST:
+ ret = snp_handle_guest_req(svm, control->exit_info_1, control->exit_info_2);
+ break;
case SVM_VMGEXIT_UNSUPPORTED_EVENT:
vcpu_unimpl(vcpu,
"vmgexit: unsupported event - exit_info_1=%#llx, exit_info_2=%#llx\n",
diff --git a/include/uapi/linux/sev-guest.h b/include/uapi/linux/sev-guest.h
index 154a87a1eca9..7bd78e258569 100644
--- a/include/uapi/linux/sev-guest.h
+++ b/include/uapi/linux/sev-guest.h
@@ -89,8 +89,17 @@ struct snp_ext_report_req {
#define SNP_GUEST_FW_ERR_MASK GENMASK_ULL(31, 0)
#define SNP_GUEST_VMM_ERR_SHIFT 32
#define SNP_GUEST_VMM_ERR(x) (((u64)x) << SNP_GUEST_VMM_ERR_SHIFT)
+#define SNP_GUEST_FW_ERR(x) ((x) & SNP_GUEST_FW_ERR_MASK)
+#define SNP_GUEST_ERR(vmm_err, fw_err) (SNP_GUEST_VMM_ERR(vmm_err) | \
+ SNP_GUEST_FW_ERR(fw_err))
+/*
+ * The GHCB spec only formally defines INVALID_LEN/BUSY VMM errors, but define
+ * a GENERIC error code such that it won't ever conflict with GHCB-defined
+ * errors if any get added in the future.
+ */
#define SNP_GUEST_VMM_ERR_INVALID_LEN 1
#define SNP_GUEST_VMM_ERR_BUSY 2
+#define SNP_GUEST_VMM_ERR_GENERIC BIT(31)
#endif /* __UAPI_LINUX_SEV_GUEST_H_ */
--
2.25.1
next prev parent reply other threads:[~2024-06-21 17:17 UTC|newest]
Thread overview: 40+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-06-21 13:40 [PATCH v1 0/5] SEV-SNP: Add KVM support for attestation and KVM_EXIT_COCO Michael Roth
2024-06-21 13:40 ` [PATCH v1 1/5] KVM: SEV: Provide support for SNP_GUEST_REQUEST NAE event Michael Roth
2024-06-21 15:52 ` Liam Merwick
2024-06-21 16:17 ` Michael Roth
2024-06-21 17:15 ` Michael Roth [this message]
2024-06-22 0:13 ` [PATCH v1-revised " Liam Merwick
2024-06-26 14:32 ` Sean Christopherson
2024-06-26 13:58 ` [PATCH v1 " Sean Christopherson
2024-06-26 15:45 ` Michael Roth
2024-06-26 17:13 ` Sean Christopherson
2024-06-26 17:42 ` Michael Roth
2024-06-26 19:54 ` Sean Christopherson
2024-06-27 14:48 ` Tom Lendacky
2024-06-27 15:35 ` Sean Christopherson
2024-06-27 16:23 ` Peter Gonda
2024-06-27 17:13 ` Tom Lendacky
2024-06-27 18:07 ` Sean Christopherson
2024-06-21 13:40 ` [PATCH v1 2/5] x86/sev: Move sev_guest.h into common SEV header Michael Roth
2024-06-21 16:42 ` Liam Merwick
2024-06-21 18:07 ` Tom Lendacky
2024-06-21 13:40 ` [PATCH v1 3/5] KVM: SEV: Provide support for SNP_EXTENDED_GUEST_REQUEST NAE event Michael Roth
2024-06-21 16:45 ` Liam Merwick
2024-06-21 19:21 ` Tom Lendacky
2024-06-22 20:28 ` Carlos Bilbao
2024-06-24 13:05 ` Tom Lendacky
2024-06-24 15:02 ` Sean Christopherson
2024-06-21 13:40 ` [PATCH v1 4/5] KVM: Introduce KVM_EXIT_COCO exit type Michael Roth
2024-06-26 14:22 ` Sean Christopherson
2024-06-26 17:30 ` Michael Roth
2024-06-28 20:08 ` Sean Christopherson
2024-06-29 0:36 ` Michael Roth
2024-07-26 7:15 ` Binbin Wu
2024-09-13 16:29 ` Dionna Amalie Glaze
2024-10-28 18:20 ` Sean Christopherson
2024-11-01 20:53 ` Dionna Amalie Glaze
2024-11-01 21:52 ` Michael Roth
2024-11-01 23:54 ` Dionna Amalie Glaze
2024-11-19 13:53 ` Michael Roth
2024-11-20 4:03 ` Binbin Wu
2024-06-21 13:40 ` [PATCH v1 5/5] KVM: SEV: Add certificate support for SNP_EXTENDED_GUEST_REQUEST events Michael Roth
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20240621171519.3180965-1-michael.roth@amd.com \
--to=michael.roth@amd.com \
--cc=aik@amd.com \
--cc=ashish.kalra@amd.com \
--cc=bp@alien8.de \
--cc=brijesh.singh@amd.com \
--cc=jroedel@suse.de \
--cc=kvm@vger.kernel.org \
--cc=liam.merwick@oracle.com \
--cc=linux-coco@lists.linux.dev \
--cc=linux-kernel@vger.kernel.org \
--cc=pankaj.gupta@amd.com \
--cc=pbonzini@redhat.com \
--cc=pgonda@google.com \
--cc=seanjc@google.com \
--cc=thomas.lendacky@amd.com \
--cc=x86@kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).