linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
* [PATCH v4 0/2] kvm: sev: Add SNP guest request throttling
@ 2025-05-14 18:41 Dionna Glaze
  2025-05-14 18:41 ` [PATCH v4 1/2] kvm: sev: Add SEV-SNP " Dionna Glaze
                   ` (2 more replies)
  0 siblings, 3 replies; 7+ messages in thread
From: Dionna Glaze @ 2025-05-14 18:41 UTC (permalink / raw)
  To: kvm; +Cc: linux-kernel, linux-coco, Dionna Glaze

The GHCB specification recommends that SNP guest requests should be
rate limited. Add a command to permit the VMM to set the rate limit
on a per-VM scale.

The AMD-SP is a global resource that must be shared across VMs, so
its time should be multiplexed across VMs fairly. It is the
responsibility of the VMM to ensure all SEV-SNP VMs have a rate limit
set such that the collective set of VMs on the machine have a rate of
access that does not exceed the device's capacity.

The sev-guest device already respects the SNP_GUEST_VMM_ERR_BUSY
result code, so utilize that result to cause the guest to retry after
waiting momentarily.

Changes since v3:
  * Rebased on master, changed module parameter to mem_enc_ioctl
    command. Changed commit descriptions. Much time has passed.
Changes since v2:
  * Rebased on v7, changed "we" wording to passive voice.
Changes since v1:
  * Added missing Ccs to patches.

Dionna Glaze (2):
  kvm: sev: Add SEV-SNP guest request throttling
  kvm: sev: If ccp is busy, report busy to guest

 .../virt/kvm/x86/amd-memory-encryption.rst    | 23 ++++++++++++
 arch/x86/include/uapi/asm/kvm.h               |  7 ++++
 arch/x86/kvm/svm/sev.c                        | 36 +++++++++++++++++++
 arch/x86/kvm/svm/svm.h                        |  2 ++
 4 files changed, 68 insertions(+)

-- 
2.49.0.1045.g170613ef41-goog


^ permalink raw reply	[flat|nested] 7+ messages in thread

* [PATCH v4 1/2] kvm: sev: Add SEV-SNP guest request throttling
  2025-05-14 18:41 [PATCH v4 0/2] kvm: sev: Add SNP guest request throttling Dionna Glaze
@ 2025-05-14 18:41 ` Dionna Glaze
  2025-05-14 18:50   ` Dionna Amalie Glaze
  2025-05-15 18:21   ` kernel test robot
  2025-05-14 18:41 ` [PATCH v4 2/2] kvm: sev: If ccp is busy, report busy to guest Dionna Glaze
  2025-05-14 18:41 ` [PATCH v4 2/2] The ccp driver can be overloaded even with guest request rate limits. 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 message sequence number when it shouldn't have Dionna Glaze
  2 siblings, 2 replies; 7+ messages in thread
From: Dionna Glaze @ 2025-05-14 18:41 UTC (permalink / raw)
  To: kvm
  Cc: linux-kernel, linux-coco, Dionna Glaze, Thomas Lendacky,
	Paolo Bonzini, Joerg Roedel, Peter Gonda, Borislav Petkov,
	Sean Christopherson

The AMD-SP is a precious resource that doesn't have a scheduler other
than a mutex lock queue. To avoid customers from causing a DoS, a
mem_enc_ioctl command for rate limiting guest requests is added.

Recommended values are {.interval_ms = 1000, .burst = 1} or
{.interval_ms = 2000, .burst = 2} to average 1 request every second.
You may need to allow 2 requests back to back to allow for the guest
to query the certificate length in an extended guest request without
a pause. The 1 second average is our target for quality of service
since empirical tests show that 64 VMs can concurrently request an
attestation report with a maximum latency of 1 second. We don't
anticipate more concurrency than that for a seldom used request for
a majority well-behaved set of VMs. The majority point is decided as
>64 VMs given the assumed 128 VM count for "extreme load".

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>
Cc: Sean Christopherson <seanjc@google.com>

Signed-off-by: Dionna Glaze <dionnaglaze@google.com>
---
 .../virt/kvm/x86/amd-memory-encryption.rst    | 23 ++++++++++++++
 arch/x86/include/uapi/asm/kvm.h               |  7 +++++
 arch/x86/kvm/svm/sev.c                        | 31 +++++++++++++++++++
 arch/x86/kvm/svm/svm.h                        |  2 ++
 4 files changed, 63 insertions(+)

diff --git a/Documentation/virt/kvm/x86/amd-memory-encryption.rst b/Documentation/virt/kvm/x86/amd-memory-encryption.rst
index 1ddb6a86ce7f..1b5b4fc35aac 100644
--- a/Documentation/virt/kvm/x86/amd-memory-encryption.rst
+++ b/Documentation/virt/kvm/x86/amd-memory-encryption.rst
@@ -572,6 +572,29 @@ Returns: 0 on success, -negative on error
 See SNP_LAUNCH_FINISH in the SEV-SNP specification [snp-fw-abi]_ for further
 details on the input parameters in ``struct kvm_sev_snp_launch_finish``.
 
+21. KVM_SEV_SNP_SET_REQUEST_THROTTLE_RATE
+-----------------------------------------
+
+The KVM_SEV_SNP_SET_REQUEST_THROTTLE_RATE command is used to set a per-VM rate
+limit on responding to requests for AMD-SP to process a guest request.
+The AMD-SP is a global resource with limited capacity, so to avoid noisy
+neighbor effects, the host may set a request rate for guests.
+
+Parameters (in): struct kvm_sev_snp_set_request_throttle_rate
+
+Returns: 0 on success, -negative on error
+
+::
+
+	struct kvm_sev_snp_set_request_throttle_rate {
+		__u32 interval_ms;
+		__u32 burst;
+	};
+
+The interval will be translated into jiffies, so if it after transformation
+the interval is 0, the command will return ``-EINVAL``. The ``burst`` value
+must be greater than 0.
+
 Device attribute API
 ====================
 
diff --git a/arch/x86/include/uapi/asm/kvm.h b/arch/x86/include/uapi/asm/kvm.h
index 460306b35a4b..d92242d9b9af 100644
--- a/arch/x86/include/uapi/asm/kvm.h
+++ b/arch/x86/include/uapi/asm/kvm.h
@@ -708,6 +708,8 @@ enum sev_cmd_id {
 	KVM_SEV_SNP_LAUNCH_UPDATE,
 	KVM_SEV_SNP_LAUNCH_FINISH,
 
+	KVM_SEV_SNP_SET_REQUEST_THROTTLE_RATE,
+
 	KVM_SEV_NR_MAX,
 };
 
@@ -877,6 +879,11 @@ struct kvm_sev_snp_launch_finish {
 	__u64 pad1[4];
 };
 
+struct kvm_sev_snp_set_request_throttle_rate {
+	__u32 interval_ms;
+	__u32 burst;
+};
+
 #define KVM_X2APIC_API_USE_32BIT_IDS            (1ULL << 0)
 #define KVM_X2APIC_API_DISABLE_BROADCAST_QUIRK  (1ULL << 1)
 
diff --git a/arch/x86/kvm/svm/sev.c b/arch/x86/kvm/svm/sev.c
index a7a7dc507336..febf4b45fddf 100644
--- a/arch/x86/kvm/svm/sev.c
+++ b/arch/x86/kvm/svm/sev.c
@@ -2535,6 +2535,29 @@ static int snp_launch_finish(struct kvm *kvm, struct kvm_sev_cmd *argp)
 	return ret;
 }
 
+static int snp_set_request_throttle_ms(struct kvm *kvm, struct kvm_sev_cmd *argp)
+{
+	struct kvm_sev_info *sev = to_kvm_sev_info(kvm);
+	struct kvm_sev_snp_set_request_throttle_rate params;
+	int ret;
+	u64 jiffies;
+
+	if (!sev_snp_guest(kvm))
+		return -ENOTTY;
+
+	if (copy_from_user(&params, u64_to_user_ptr(argp->data), sizeof(params)))
+		return -EFAULT;
+
+	jiffies = (params.interval_ms * HZ) / 1000;
+
+	if (!jiffies || !params.burst)
+		return -EINVAL;
+
+	ratelimit_state_init(&sev->snp_guest_msg_rs, jiffies, params.burst);
+
+	return 0;
+}
+
 int sev_mem_enc_ioctl(struct kvm *kvm, void __user *argp)
 {
 	struct kvm_sev_cmd sev_cmd;
@@ -2640,6 +2663,9 @@ int sev_mem_enc_ioctl(struct kvm *kvm, void __user *argp)
 	case KVM_SEV_SNP_LAUNCH_FINISH:
 		r = snp_launch_finish(kvm, &sev_cmd);
 		break;
+	case KVM_SEV_SNP_SET_REQUEST_THROTTLE_RATE_MS:
+		r = snp_set_request_throttle_ms(kvm, &sev_cmd);
+		break;
 	default:
 		r = -EINVAL;
 		goto out;
@@ -4015,6 +4041,11 @@ 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)) {
+		rc = SNP_GUEST_VMM_ERR_BUSY;
+		goto out_unlock;
+	}
+
 	if (kvm_read_guest(kvm, req_gpa, sev->guest_req_buf, PAGE_SIZE)) {
 		ret = -EIO;
 		goto out_unlock;
diff --git a/arch/x86/kvm/svm/svm.h b/arch/x86/kvm/svm/svm.h
index f16b068c4228..0a7c8d3a7560 100644
--- a/arch/x86/kvm/svm/svm.h
+++ b/arch/x86/kvm/svm/svm.h
@@ -112,6 +112,8 @@ struct kvm_sev_info {
 	void *guest_req_buf;    /* Bounce buffer for SNP Guest Request input */
 	void *guest_resp_buf;   /* Bounce buffer for SNP Guest Request output */
 	struct mutex guest_req_mutex; /* Must acquire before using bounce buffers */
+
+	struct ratelimit_state snp_guest_msg_rs; /* Limit guest requests */
 };
 
 struct kvm_svm {
-- 
2.49.0.1045.g170613ef41-goog


^ permalink raw reply related	[flat|nested] 7+ messages in thread

* [PATCH v4 2/2] kvm: sev: If ccp is busy, report busy to guest
  2025-05-14 18:41 [PATCH v4 0/2] kvm: sev: Add SNP guest request throttling Dionna Glaze
  2025-05-14 18:41 ` [PATCH v4 1/2] kvm: sev: Add SEV-SNP " Dionna Glaze
@ 2025-05-14 18:41 ` Dionna Glaze
  2025-05-14 18:41 ` [PATCH v4 2/2] The ccp driver can be overloaded even with guest request rate limits. 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 message sequence number when it shouldn't have Dionna Glaze
  2 siblings, 0 replies; 7+ messages in thread
From: Dionna Glaze @ 2025-05-14 18:41 UTC (permalink / raw)
  To: kvm
  Cc: linux-kernel, linux-coco, Dionna Glaze, Thomas Lendacky,
	Paolo Bonzini, Joerg Roedel, Peter Gonda, Borislav Petkov,
	Sean Christopherson

The ccp driver can be overloaded even with guest request rate limits.
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
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>
Cc: Sean Christopherson <seanjc@google.com>

Signed-off-by: Dionna Glaze <dionnaglaze@google.com>
---
 arch/x86/kvm/svm/sev.c | 5 +++++
 1 file changed, 5 insertions(+)

diff --git a/arch/x86/kvm/svm/sev.c b/arch/x86/kvm/svm/sev.c
index febf4b45fddf..c1bd82c26a11 100644
--- a/arch/x86/kvm/svm/sev.c
+++ b/arch/x86/kvm/svm/sev.c
@@ -4061,6 +4061,11 @@ static int snp_handle_guest_req(struct vcpu_svm *svm, gpa_t req_gpa, gpa_t resp_
 	 * the PSP is dead and commands are timing out.
 	 */
 	ret = sev_issue_cmd(kvm, SEV_CMD_SNP_GUEST_REQUEST, &data, &fw_err);
+	if (ret == -EBUSY) {
+		svm_vmgexit_no_action(svm, SNP_GUEST_ERR(SNP_GUEST_VMM_ERR_BUSY, fw_err));
+		ret = 1;
+		goto out_unlock;
+	}
 	if (ret && !fw_err)
 		goto out_unlock;
 
-- 
2.49.0.1045.g170613ef41-goog


^ permalink raw reply related	[flat|nested] 7+ messages in thread

* [PATCH v4 2/2] The ccp driver can be overloaded even with guest request rate limits. 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 message sequence number when it shouldn't have.
  2025-05-14 18:41 [PATCH v4 0/2] kvm: sev: Add SNP guest request throttling Dionna Glaze
  2025-05-14 18:41 ` [PATCH v4 1/2] kvm: sev: Add SEV-SNP " Dionna Glaze
  2025-05-14 18:41 ` [PATCH v4 2/2] kvm: sev: If ccp is busy, report busy to guest Dionna Glaze
@ 2025-05-14 18:41 ` Dionna Glaze
  2025-05-14 18:47   ` Dionna Amalie Glaze
  2 siblings, 1 reply; 7+ messages in thread
From: Dionna Glaze @ 2025-05-14 18:41 UTC (permalink / raw)
  To: kvm
  Cc: linux-kernel, linux-coco, Dionna Glaze, Thomas Lendacky,
	Paolo Bonzini, Joerg Roedel, Peter Gonda, Borislav Petkov,
	Sean Christopherson

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>
Cc: Sean Christopherson <seanjc@google.com>

Signed-off-by: Dionna Glaze <dionnaglaze@google.com>
---
 arch/x86/kvm/svm/sev.c | 5 +++++
 1 file changed, 5 insertions(+)

diff --git a/arch/x86/kvm/svm/sev.c b/arch/x86/kvm/svm/sev.c
index ddbfdce9dc18..5901a7f59f88 100644
--- a/arch/x86/kvm/svm/sev.c
+++ b/arch/x86/kvm/svm/sev.c
@@ -4065,6 +4065,11 @@ static int snp_handle_guest_req(struct vcpu_svm *svm, gpa_t req_gpa, gpa_t resp_
 	 * the PSP is dead and commands are timing out.
 	 */
 	ret = sev_issue_cmd(kvm, SEV_CMD_SNP_GUEST_REQUEST, &data, &fw_err);
+	if (ret == -EBUSY) {
+		svm_vmgexit_no_action(svm, SNP_GUEST_ERR(SNP_GUEST_VMM_ERR_BUSY, fw_err));
+		ret = 1;
+		goto out_unlock;
+	}
 	if (ret && !fw_err)
 		goto out_unlock;
 
-- 
2.49.0.1045.g170613ef41-goog


^ permalink raw reply related	[flat|nested] 7+ messages in thread

* Re: [PATCH v4 2/2] The ccp driver can be overloaded even with guest request rate limits. 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 message sequence number when it shouldn't have.
  2025-05-14 18:41 ` [PATCH v4 2/2] The ccp driver can be overloaded even with guest request rate limits. 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 message sequence number when it shouldn't have Dionna Glaze
@ 2025-05-14 18:47   ` Dionna Amalie Glaze
  0 siblings, 0 replies; 7+ messages in thread
From: Dionna Amalie Glaze @ 2025-05-14 18:47 UTC (permalink / raw)
  To: kvm
  Cc: linux-kernel, linux-coco, Thomas Lendacky, Paolo Bonzini,
	Joerg Roedel, Peter Gonda, Borislav Petkov, Sean Christopherson

On Wed, May 14, 2025 at 11:42 AM Dionna Glaze <dionnaglaze@google.com> wrote:
>
> Instead, when ccp returns -EBUSY, that is reported to userspace as the
> throttling return value.
>

Ah, disregard this email. Globbed one too many patch files.


-- 
-Dionna Glaze, PhD, CISSP, CCSP (she/her)

^ permalink raw reply	[flat|nested] 7+ messages in thread

* Re: [PATCH v4 1/2] kvm: sev: Add SEV-SNP guest request throttling
  2025-05-14 18:41 ` [PATCH v4 1/2] kvm: sev: Add SEV-SNP " Dionna Glaze
@ 2025-05-14 18:50   ` Dionna Amalie Glaze
  2025-05-15 18:21   ` kernel test robot
  1 sibling, 0 replies; 7+ messages in thread
From: Dionna Amalie Glaze @ 2025-05-14 18:50 UTC (permalink / raw)
  To: kvm
  Cc: linux-kernel, linux-coco, Thomas Lendacky, Paolo Bonzini,
	Joerg Roedel, Peter Gonda, Borislav Petkov, Sean Christopherson

On Wed, May 14, 2025 at 11:41 AM Dionna Glaze <dionnaglaze@google.com> wrote:
>
> The AMD-SP is a precious resource that doesn't have a scheduler other
> than a mutex lock queue. To avoid customers from causing a DoS, a
> mem_enc_ioctl command for rate limiting guest requests is added.
>
> Recommended values are {.interval_ms = 1000, .burst = 1} or
> {.interval_ms = 2000, .burst = 2} to average 1 request every second.
> You may need to allow 2 requests back to back to allow for the guest
> to query the certificate length in an extended guest request without
> a pause. The 1 second average is our target for quality of service
> since empirical tests show that 64 VMs can concurrently request an
> attestation report with a maximum latency of 1 second. We don't
> anticipate more concurrency than that for a seldom used request for
> a majority well-behaved set of VMs. The majority point is decided as
> >64 VMs given the assumed 128 VM count for "extreme load".
>
> 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>
> Cc: Sean Christopherson <seanjc@google.com>
>
> Signed-off-by: Dionna Glaze <dionnaglaze@google.com>
> ---
>  .../virt/kvm/x86/amd-memory-encryption.rst    | 23 ++++++++++++++
>  arch/x86/include/uapi/asm/kvm.h               |  7 +++++
>  arch/x86/kvm/svm/sev.c                        | 31 +++++++++++++++++++
>  arch/x86/kvm/svm/svm.h                        |  2 ++
>  4 files changed, 63 insertions(+)
>
> diff --git a/Documentation/virt/kvm/x86/amd-memory-encryption.rst b/Documentation/virt/kvm/x86/amd-memory-encryption.rst
> index 1ddb6a86ce7f..1b5b4fc35aac 100644
> --- a/Documentation/virt/kvm/x86/amd-memory-encryption.rst
> +++ b/Documentation/virt/kvm/x86/amd-memory-encryption.rst
> @@ -572,6 +572,29 @@ Returns: 0 on success, -negative on error
>  See SNP_LAUNCH_FINISH in the SEV-SNP specification [snp-fw-abi]_ for further
>  details on the input parameters in ``struct kvm_sev_snp_launch_finish``.
>
> +21. KVM_SEV_SNP_SET_REQUEST_THROTTLE_RATE
> +-----------------------------------------
> +
> +The KVM_SEV_SNP_SET_REQUEST_THROTTLE_RATE command is used to set a per-VM rate
> +limit on responding to requests for AMD-SP to process a guest request.
> +The AMD-SP is a global resource with limited capacity, so to avoid noisy
> +neighbor effects, the host may set a request rate for guests.
> +
> +Parameters (in): struct kvm_sev_snp_set_request_throttle_rate
> +
> +Returns: 0 on success, -negative on error
> +
> +::
> +
> +       struct kvm_sev_snp_set_request_throttle_rate {
> +               __u32 interval_ms;
> +               __u32 burst;
> +       };
> +
> +The interval will be translated into jiffies, so if it after transformation
> +the interval is 0, the command will return ``-EINVAL``. The ``burst`` value
> +must be greater than 0.
> +
>  Device attribute API
>  ====================
>
> diff --git a/arch/x86/include/uapi/asm/kvm.h b/arch/x86/include/uapi/asm/kvm.h
> index 460306b35a4b..d92242d9b9af 100644
> --- a/arch/x86/include/uapi/asm/kvm.h
> +++ b/arch/x86/include/uapi/asm/kvm.h
> @@ -708,6 +708,8 @@ enum sev_cmd_id {
>         KVM_SEV_SNP_LAUNCH_UPDATE,
>         KVM_SEV_SNP_LAUNCH_FINISH,
>
> +       KVM_SEV_SNP_SET_REQUEST_THROTTLE_RATE,
> +
>         KVM_SEV_NR_MAX,
>  };
>
> @@ -877,6 +879,11 @@ struct kvm_sev_snp_launch_finish {
>         __u64 pad1[4];
>  };
>
> +struct kvm_sev_snp_set_request_throttle_rate {
> +       __u32 interval_ms;
> +       __u32 burst;
> +};
> +
>  #define KVM_X2APIC_API_USE_32BIT_IDS            (1ULL << 0)
>  #define KVM_X2APIC_API_DISABLE_BROADCAST_QUIRK  (1ULL << 1)
>
> diff --git a/arch/x86/kvm/svm/sev.c b/arch/x86/kvm/svm/sev.c
> index a7a7dc507336..febf4b45fddf 100644
> --- a/arch/x86/kvm/svm/sev.c
> +++ b/arch/x86/kvm/svm/sev.c
> @@ -2535,6 +2535,29 @@ static int snp_launch_finish(struct kvm *kvm, struct kvm_sev_cmd *argp)
>         return ret;
>  }
>
> +static int snp_set_request_throttle_ms(struct kvm *kvm, struct kvm_sev_cmd *argp)
> +{
> +       struct kvm_sev_info *sev = to_kvm_sev_info(kvm);
> +       struct kvm_sev_snp_set_request_throttle_rate params;
> +       int ret;
> +       u64 jiffies;
> +
> +       if (!sev_snp_guest(kvm))
> +               return -ENOTTY;
> +
> +       if (copy_from_user(&params, u64_to_user_ptr(argp->data), sizeof(params)))
> +               return -EFAULT;
> +
> +       jiffies = (params.interval_ms * HZ) / 1000;
> +
> +       if (!jiffies || !params.burst)
> +               return -EINVAL;
> +
> +       ratelimit_state_init(&sev->snp_guest_msg_rs, jiffies, params.burst);
> +
> +       return 0;
> +}
> +
>  int sev_mem_enc_ioctl(struct kvm *kvm, void __user *argp)
>  {
>         struct kvm_sev_cmd sev_cmd;
> @@ -2640,6 +2663,9 @@ int sev_mem_enc_ioctl(struct kvm *kvm, void __user *argp)
>         case KVM_SEV_SNP_LAUNCH_FINISH:
>                 r = snp_launch_finish(kvm, &sev_cmd);
>                 break;
> +       case KVM_SEV_SNP_SET_REQUEST_THROTTLE_RATE_MS:
> +               r = snp_set_request_throttle_ms(kvm, &sev_cmd);
> +               break;
>         default:
>                 r = -EINVAL;
>                 goto out;
> @@ -4015,6 +4041,11 @@ 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)) {
> +               rc = SNP_GUEST_VMM_ERR_BUSY;

embarrassing. My build totally skipped this error. Disregard as well.

> +               goto out_unlock;
> +       }
> +
>         if (kvm_read_guest(kvm, req_gpa, sev->guest_req_buf, PAGE_SIZE)) {
>                 ret = -EIO;
>                 goto out_unlock;
> diff --git a/arch/x86/kvm/svm/svm.h b/arch/x86/kvm/svm/svm.h
> index f16b068c4228..0a7c8d3a7560 100644
> --- a/arch/x86/kvm/svm/svm.h
> +++ b/arch/x86/kvm/svm/svm.h
> @@ -112,6 +112,8 @@ struct kvm_sev_info {
>         void *guest_req_buf;    /* Bounce buffer for SNP Guest Request input */
>         void *guest_resp_buf;   /* Bounce buffer for SNP Guest Request output */
>         struct mutex guest_req_mutex; /* Must acquire before using bounce buffers */
> +
> +       struct ratelimit_state snp_guest_msg_rs; /* Limit guest requests */
>  };
>
>  struct kvm_svm {
> --
> 2.49.0.1045.g170613ef41-goog
>


-- 
-Dionna Glaze, PhD, CISSP, CCSP (she/her)

^ permalink raw reply	[flat|nested] 7+ messages in thread

* Re: [PATCH v4 1/2] kvm: sev: Add SEV-SNP guest request throttling
  2025-05-14 18:41 ` [PATCH v4 1/2] kvm: sev: Add SEV-SNP " Dionna Glaze
  2025-05-14 18:50   ` Dionna Amalie Glaze
@ 2025-05-15 18:21   ` kernel test robot
  1 sibling, 0 replies; 7+ messages in thread
From: kernel test robot @ 2025-05-15 18:21 UTC (permalink / raw)
  To: Dionna Glaze, kvm
  Cc: oe-kbuild-all, linux-kernel, linux-coco, Dionna Glaze,
	Thomas Lendacky, Paolo Bonzini, Joerg Roedel, Peter Gonda,
	Borislav Petkov, Sean Christopherson

Hi Dionna,

kernel test robot noticed the following build errors:

[auto build test ERROR on kvm/queue]
[also build test ERROR on kvm/next mst-vhost/linux-next linus/master v6.15-rc6 next-20250515]
[cannot apply to kvm/linux-next]
[If your patch is applied to the wrong git tree, kindly drop us a note.
And when submitting patch, we suggest to use '--base' as documented in
https://git-scm.com/docs/git-format-patch#_base_tree_information]

url:    https://github.com/intel-lab-lkp/linux/commits/Dionna-Glaze/kvm-sev-Add-SEV-SNP-guest-request-throttling/20250515-064452
base:   https://git.kernel.org/pub/scm/virt/kvm/kvm.git queue
patch link:    https://lore.kernel.org/r/20250514184136.238446-2-dionnaglaze%40google.com
patch subject: [PATCH v4 1/2] kvm: sev: Add SEV-SNP guest request throttling
config: x86_64-rhel-9.4 (https://download.01.org/0day-ci/archive/20250516/202505160203.9PdDhrOM-lkp@intel.com/config)
compiler: gcc-12 (Debian 12.2.0-14) 12.2.0
reproduce (this is a W=1 build): (https://download.01.org/0day-ci/archive/20250516/202505160203.9PdDhrOM-lkp@intel.com/reproduce)

If you fix the issue in a separate patch/commit (i.e. not just a new version of
the same patch/commit), kindly add following tags
| Reported-by: kernel test robot <lkp@intel.com>
| Closes: https://lore.kernel.org/oe-kbuild-all/202505160203.9PdDhrOM-lkp@intel.com/

All errors (new ones prefixed by >>):

   arch/x86/kvm/svm/sev.c: In function 'snp_set_request_throttle_ms':
   arch/x86/kvm/svm/sev.c:2542:13: warning: unused variable 'ret' [-Wunused-variable]
    2542 |         int ret;
         |             ^~~
   arch/x86/kvm/svm/sev.c: In function 'sev_mem_enc_ioctl':
>> arch/x86/kvm/svm/sev.c:2666:14: error: 'KVM_SEV_SNP_SET_REQUEST_THROTTLE_RATE_MS' undeclared (first use in this function); did you mean 'KVM_SEV_SNP_SET_REQUEST_THROTTLE_RATE'?
    2666 |         case KVM_SEV_SNP_SET_REQUEST_THROTTLE_RATE_MS:
         |              ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
         |              KVM_SEV_SNP_SET_REQUEST_THROTTLE_RATE
   arch/x86/kvm/svm/sev.c:2666:14: note: each undeclared identifier is reported only once for each function it appears in
   arch/x86/kvm/svm/sev.c: In function 'snp_handle_guest_req':
>> arch/x86/kvm/svm/sev.c:4039:17: error: 'rc' undeclared (first use in this function); did you mean 'rq'?
    4039 |                 rc = SNP_GUEST_VMM_ERR_BUSY;
         |                 ^~
         |                 rq


vim +2666 arch/x86/kvm/svm/sev.c

  2537	
  2538	static int snp_set_request_throttle_ms(struct kvm *kvm, struct kvm_sev_cmd *argp)
  2539	{
  2540		struct kvm_sev_info *sev = to_kvm_sev_info(kvm);
  2541		struct kvm_sev_snp_set_request_throttle_rate params;
> 2542		int ret;
  2543		u64 jiffies;
  2544	
  2545		if (!sev_snp_guest(kvm))
  2546			return -ENOTTY;
  2547	
  2548		if (copy_from_user(&params, u64_to_user_ptr(argp->data), sizeof(params)))
  2549			return -EFAULT;
  2550	
  2551		jiffies = (params.interval_ms * HZ) / 1000;
  2552	
  2553		if (!jiffies || !params.burst)
  2554			return -EINVAL;
  2555	
  2556		ratelimit_state_init(&sev->snp_guest_msg_rs, jiffies, params.burst);
  2557	
  2558		return 0;
  2559	}
  2560	
  2561	int sev_mem_enc_ioctl(struct kvm *kvm, void __user *argp)
  2562	{
  2563		struct kvm_sev_cmd sev_cmd;
  2564		int r;
  2565	
  2566		if (!sev_enabled)
  2567			return -ENOTTY;
  2568	
  2569		if (!argp)
  2570			return 0;
  2571	
  2572		if (copy_from_user(&sev_cmd, argp, sizeof(struct kvm_sev_cmd)))
  2573			return -EFAULT;
  2574	
  2575		mutex_lock(&kvm->lock);
  2576	
  2577		/* Only the enc_context_owner handles some memory enc operations. */
  2578		if (is_mirroring_enc_context(kvm) &&
  2579		    !is_cmd_allowed_from_mirror(sev_cmd.id)) {
  2580			r = -EINVAL;
  2581			goto out;
  2582		}
  2583	
  2584		/*
  2585		 * Once KVM_SEV_INIT2 initializes a KVM instance as an SNP guest, only
  2586		 * allow the use of SNP-specific commands.
  2587		 */
  2588		if (sev_snp_guest(kvm) && sev_cmd.id < KVM_SEV_SNP_LAUNCH_START) {
  2589			r = -EPERM;
  2590			goto out;
  2591		}
  2592	
  2593		switch (sev_cmd.id) {
  2594		case KVM_SEV_ES_INIT:
  2595			if (!sev_es_enabled) {
  2596				r = -ENOTTY;
  2597				goto out;
  2598			}
  2599			fallthrough;
  2600		case KVM_SEV_INIT:
  2601			r = sev_guest_init(kvm, &sev_cmd);
  2602			break;
  2603		case KVM_SEV_INIT2:
  2604			r = sev_guest_init2(kvm, &sev_cmd);
  2605			break;
  2606		case KVM_SEV_LAUNCH_START:
  2607			r = sev_launch_start(kvm, &sev_cmd);
  2608			break;
  2609		case KVM_SEV_LAUNCH_UPDATE_DATA:
  2610			r = sev_launch_update_data(kvm, &sev_cmd);
  2611			break;
  2612		case KVM_SEV_LAUNCH_UPDATE_VMSA:
  2613			r = sev_launch_update_vmsa(kvm, &sev_cmd);
  2614			break;
  2615		case KVM_SEV_LAUNCH_MEASURE:
  2616			r = sev_launch_measure(kvm, &sev_cmd);
  2617			break;
  2618		case KVM_SEV_LAUNCH_FINISH:
  2619			r = sev_launch_finish(kvm, &sev_cmd);
  2620			break;
  2621		case KVM_SEV_GUEST_STATUS:
  2622			r = sev_guest_status(kvm, &sev_cmd);
  2623			break;
  2624		case KVM_SEV_DBG_DECRYPT:
  2625			r = sev_dbg_crypt(kvm, &sev_cmd, true);
  2626			break;
  2627		case KVM_SEV_DBG_ENCRYPT:
  2628			r = sev_dbg_crypt(kvm, &sev_cmd, false);
  2629			break;
  2630		case KVM_SEV_LAUNCH_SECRET:
  2631			r = sev_launch_secret(kvm, &sev_cmd);
  2632			break;
  2633		case KVM_SEV_GET_ATTESTATION_REPORT:
  2634			r = sev_get_attestation_report(kvm, &sev_cmd);
  2635			break;
  2636		case KVM_SEV_SEND_START:
  2637			r = sev_send_start(kvm, &sev_cmd);
  2638			break;
  2639		case KVM_SEV_SEND_UPDATE_DATA:
  2640			r = sev_send_update_data(kvm, &sev_cmd);
  2641			break;
  2642		case KVM_SEV_SEND_FINISH:
  2643			r = sev_send_finish(kvm, &sev_cmd);
  2644			break;
  2645		case KVM_SEV_SEND_CANCEL:
  2646			r = sev_send_cancel(kvm, &sev_cmd);
  2647			break;
  2648		case KVM_SEV_RECEIVE_START:
  2649			r = sev_receive_start(kvm, &sev_cmd);
  2650			break;
  2651		case KVM_SEV_RECEIVE_UPDATE_DATA:
  2652			r = sev_receive_update_data(kvm, &sev_cmd);
  2653			break;
  2654		case KVM_SEV_RECEIVE_FINISH:
  2655			r = sev_receive_finish(kvm, &sev_cmd);
  2656			break;
  2657		case KVM_SEV_SNP_LAUNCH_START:
  2658			r = snp_launch_start(kvm, &sev_cmd);
  2659			break;
  2660		case KVM_SEV_SNP_LAUNCH_UPDATE:
  2661			r = snp_launch_update(kvm, &sev_cmd);
  2662			break;
  2663		case KVM_SEV_SNP_LAUNCH_FINISH:
  2664			r = snp_launch_finish(kvm, &sev_cmd);
  2665			break;
> 2666		case KVM_SEV_SNP_SET_REQUEST_THROTTLE_RATE_MS:
  2667			r = snp_set_request_throttle_ms(kvm, &sev_cmd);
  2668			break;
  2669		default:
  2670			r = -EINVAL;
  2671			goto out;
  2672		}
  2673	
  2674		if (copy_to_user(argp, &sev_cmd, sizeof(struct kvm_sev_cmd)))
  2675			r = -EFAULT;
  2676	
  2677	out:
  2678		mutex_unlock(&kvm->lock);
  2679		return r;
  2680	}
  2681	

-- 
0-DAY CI Kernel Test Service
https://github.com/intel/lkp-tests/wiki

^ permalink raw reply	[flat|nested] 7+ messages in thread

end of thread, other threads:[~2025-05-15 18:21 UTC | newest]

Thread overview: 7+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2025-05-14 18:41 [PATCH v4 0/2] kvm: sev: Add SNP guest request throttling Dionna Glaze
2025-05-14 18:41 ` [PATCH v4 1/2] kvm: sev: Add SEV-SNP " Dionna Glaze
2025-05-14 18:50   ` Dionna Amalie Glaze
2025-05-15 18:21   ` kernel test robot
2025-05-14 18:41 ` [PATCH v4 2/2] kvm: sev: If ccp is busy, report busy to guest Dionna Glaze
2025-05-14 18:41 ` [PATCH v4 2/2] The ccp driver can be overloaded even with guest request rate limits. 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 message sequence number when it shouldn't have Dionna Glaze
2025-05-14 18:47   ` Dionna Amalie Glaze

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).