mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: Tom Lendacky <thomas.lendacky@amd.com>
To: Dionna Glaze <dionnaglaze@google.com>,
	linux-kernel@vger.kernel.org, x86@kernel.org
Cc: Paolo Bonzini <pbonzini@redhat.com>,
	Joerg Roedel <jroedel@suse.de>, Peter Gonda <pgonda@google.com>,
	Thomas Gleixner <tglx@linutronix.de>,
	Dave Hansen <dave.hansen@linux.intel.com>
Subject: Re: [PATCH 2/2] virt/coco/sev-guest: interpret VMM errors from guest request
Date: Thu, 13 Oct 2022 16:59:07 -0500	[thread overview]
Message-ID: <ba5b3553-370f-3114-b920-5efe9b40ab0f@amd.com> (raw)
In-Reply-To: <20221013160040.2858732-3-dionnaglaze@google.com>

On 10/13/22 11:00, Dionna Glaze wrote:
> The GHCB specification states that the upper 32 bits of exitinfo2 are
> for the VMM's error codes. The sev-guest ABI has already locked in

I will have to update the GHCB specification for SNP Guest Request and SNP 
Extended Guest Request for this change. I believe that there isn't an 
impact from a backwards compatibility since software should be checking 
for specific values for success or the need for additional memory.

Adding a (new) return code will result in an error return for older 
software, which is ok.

> that the fw_err status of the input will be 64 bits, and that
> BIT_ULL(32) means that the extended guest request's data buffer was too
> small, so we have to keep that ABI. This patch deprecates the fw_err
> field name in the request to exitinfo2.
> 
> We can still interpret the upper 32 bits of exitinfo2 for the user
> anyway in case the request gets throttled. That makes the interface more
> user-friendly.
> 
> Cc: Tom Lendacky <Thomas.Lendacky@amd.com>
> Cc: Paolo Bonzini <pbonzini@redhat.com>
> Cc: Joerg Roedel <jroedel@suse.de>
> Cc: Peter Gonda <pgonda@google.com>
> Cc: Thomas Gleixner <tglx@linutronix.de>
> Cc: Dave Hansen <dave.hansen@linux.intel.com>
> Signed-off-by: Dionna Glaze <dionnaglaze@google.com>
> ---
>   drivers/virt/coco/sev-guest/sev-guest.c | 34 +++++++++++++++++--------
>   include/uapi/linux/sev-guest.h          | 17 +++++++++++--
>   2 files changed, 38 insertions(+), 13 deletions(-)
> 
> diff --git a/drivers/virt/coco/sev-guest/sev-guest.c b/drivers/virt/coco/sev-guest/sev-guest.c
> index f422f9c58ba7..8bc435cbd7e3 100644
> --- a/drivers/virt/coco/sev-guest/sev-guest.c
> +++ b/drivers/virt/coco/sev-guest/sev-guest.c
> @@ -303,9 +303,10 @@ static int enc_payload(struct snp_guest_dev *snp_dev, u64 seqno, int version, u8
>   
>   static int handle_guest_request(struct snp_guest_dev *snp_dev, u64 exit_code, int msg_ver,
>   				u8 type, void *req_buf, size_t req_sz, void *resp_buf,
> -				u32 resp_sz, __u64 *fw_err)
> +				u32 resp_sz, __u64 *exitinfo2)
>   {
> -	unsigned long err;
> +	unsigned long _exitinfo2 = 0;
> +	unsigned int vmm_err;
>   	u64 seqno;
>   	int rc;
>   
> @@ -322,9 +323,20 @@ static int handle_guest_request(struct snp_guest_dev *snp_dev, u64 exit_code, in
>   		return rc;
>   
>   	/* Call firmware to process the request */
> -	rc = snp_issue_guest_request(exit_code, &snp_dev->input, &err);
> -	if (fw_err)
> -		*fw_err = err;
> +	rc = snp_issue_guest_request(exit_code, &snp_dev->input, &_exitinfo2);
> +	if (exitinfo2)
> +		*exitinfo2 = _exitinfo2;
> +
> +	vmm_err = _exitinfo2 >> SNP_GUEST_VMM_ERR_SHIFT;
> +	/* The host may return EBUSY if the request has been throttled. */
> +	if (vmm_err == SNP_GUEST_VMM_ERR_BUSY)
> +		return -EAGAIN;
> +
> +	if (vmm_err && vmm_err != SNP_GUEST_VMM_ERR_INVALID_LEN) {
> +		pr_err("sev-guest: host returned unknown error code: %d\n",
> +		       vmm_err);
> +		return -EINVAL;
> +	}
>   
>   	if (rc)
>   		return rc;
> @@ -378,7 +390,7 @@ static int get_report(struct snp_guest_dev *snp_dev, struct snp_guest_request_io
>   
>   	rc = handle_guest_request(snp_dev, SVM_VMGEXIT_GUEST_REQUEST, arg->msg_version,
>   				  SNP_MSG_REPORT_REQ, &req, sizeof(req), resp->data,
> -				  resp_len, &arg->fw_err);
> +				  resp_len, &arg->exitinfo2);
>   	if (rc)
>   		goto e_free;
>   
> @@ -418,7 +430,7 @@ static int get_derived_key(struct snp_guest_dev *snp_dev, struct snp_guest_reque
>   
>   	rc = handle_guest_request(snp_dev, SVM_VMGEXIT_GUEST_REQUEST, arg->msg_version,
>   				  SNP_MSG_KEY_REQ, &req, sizeof(req), buf, resp_len,
> -				  &arg->fw_err);
> +				  &arg->exitinfo2);
>   	if (rc)
>   		return rc;
>   
> @@ -480,10 +492,10 @@ static int get_ext_report(struct snp_guest_dev *snp_dev, struct snp_guest_reques
>   	snp_dev->input.data_npages = npages;
>   	ret = handle_guest_request(snp_dev, SVM_VMGEXIT_EXT_GUEST_REQUEST, arg->msg_version,
>   				   SNP_MSG_REPORT_REQ, &req.data,
> -				   sizeof(req.data), resp->data, resp_len, &arg->fw_err);
> +				   sizeof(req.data), resp->data, resp_len, &arg->exitinfo2);
>   
>   	/* If certs length is invalid then copy the returned length */
> -	if (arg->fw_err == SNP_GUEST_REQ_INVALID_LEN) {
> +	if (arg->vmm_error == SNP_GUEST_VMM_ERR_INVALID_LEN) {
>   		req.certs_len = snp_dev->input.data_npages << PAGE_SHIFT;
>   
>   		if (copy_to_user((void __user *)arg->req_data, &req, sizeof(req)))
> @@ -518,7 +530,7 @@ static long snp_guest_ioctl(struct file *file, unsigned int ioctl, unsigned long
>   	if (copy_from_user(&input, argp, sizeof(input)))
>   		return -EFAULT;
>   
> -	input.fw_err = 0xff;
> +	input.exitinfo2 = 0xff;
>   
>   	/* Message version must be non-zero */
>   	if (!input.msg_version)
> @@ -549,7 +561,7 @@ static long snp_guest_ioctl(struct file *file, unsigned int ioctl, unsigned long
>   
>   	mutex_unlock(&snp_cmd_mutex);
>   
> -	if (input.fw_err && copy_to_user(argp, &input, sizeof(input)))
> +	if (input.exitinfo2 && copy_to_user(argp, &input, sizeof(input)))
>   		return -EFAULT;
>   
>   	return ret;
> diff --git a/include/uapi/linux/sev-guest.h b/include/uapi/linux/sev-guest.h
> index 256aaeff7e65..0654a652e4dc 100644
> --- a/include/uapi/linux/sev-guest.h
> +++ b/include/uapi/linux/sev-guest.h
> @@ -12,6 +12,7 @@
>   #ifndef __UAPI_LINUX_SEV_GUEST_H_
>   #define __UAPI_LINUX_SEV_GUEST_H_
>   
> +#include <linux/errno.h>
>   #include <linux/types.h>
>   
>   struct snp_report_req {
> @@ -52,8 +53,15 @@ struct snp_guest_request_ioctl {
>   	__u64 req_data;
>   	__u64 resp_data;
>   
> -	/* firmware error code on failure (see psp-sev.h) */
> -	__u64 fw_err;
> +	/* bits[63:32]: VMM error code, bits[31:0] firmware error code (see psp-sev.h) */
> +	union {
> +		__u64 exitinfo2;
> +		__u64 fw_err; /* Name deprecated in favor of others */
> +		struct {
> +			__u32 fw_error;
> +			__u32 vmm_error;
> +		};
> +	};
>   };
>   
>   struct snp_ext_report_req {
> @@ -77,4 +85,9 @@ struct snp_ext_report_req {
>   /* Get SNP extended report as defined in the GHCB specification version 2. */
>   #define SNP_GET_EXT_REPORT _IOWR(SNP_GUEST_REQ_IOC_TYPE, 0x2, struct snp_guest_request_ioctl)
>   
> +
> +#define SNP_GUEST_VMM_ERR_SHIFT		32
> +#define SNP_GUEST_VMM_ERR_INVALID_LEN	1
> +#define SNP_GUEST_VMM_ERR_BUSY		EBUSY

The GHCB spec has to be OS agnostic, so in the specification I would be 
adding a value of 16 so that this matches. Not sure we don't want to just 
use 2. We might be able to say the VMM error codes will follow the POSIX 
standard, but then the currently defined value of 1 doesn't quite match an 
EPERM.

Thoughts?

Thanks,
Tom


> +
>   #endif /* __UAPI_LINUX_SEV_GUEST_H_ */

  reply	other threads:[~2022-10-13 21:59 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-10-13 16:00 [PATCH 0/2] Add throttling detection to sev-guest Dionna Glaze
2022-10-13 16:00 ` [PATCH 1/2] x86/sev: Rename snp_guest_issue_request's fw_err Dionna Glaze
2022-10-13 16:00 ` [PATCH 2/2] virt/coco/sev-guest: interpret VMM errors from guest request Dionna Glaze
2022-10-13 21:59   ` Tom Lendacky [this message]
2022-10-18 16:20     ` Dionna Amalie Glaze

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=ba5b3553-370f-3114-b920-5efe9b40ab0f@amd.com \
    --to=thomas.lendacky@amd.com \
    --cc=dave.hansen@linux.intel.com \
    --cc=dionnaglaze@google.com \
    --cc=jroedel@suse.de \
    --cc=linux-kernel@vger.kernel.org \
    --cc=pbonzini@redhat.com \
    --cc=pgonda@google.com \
    --cc=tglx@linutronix.de \
    --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

all inboxes | Powered by JetHome®