From: "Tycho Andersen (AMD)" <tycho@kernel.org>
The kernel allows setting the RAPL_DIS policy bit, but had no way to set
the RAPL_DIS bit during SNP_INIT_EX. Setting the policy bit would always
result in:
[ 898.840286] ccp 0000:a9:00.5: sev command 0xa0 failed (0x00000007)
Allow setting the RAPL_DIS bit during SNP_INIT_EX via a module parameter.
If the hardware does not support RAPL_DIS, log and disable the module
parameter.
Signed-off-by: Tycho Andersen (AMD) <tycho@kernel.org>
---
drivers/crypto/ccp/sev-dev.c | 14 ++++++++++++++
1 file changed, 14 insertions(+)
diff --git a/drivers/crypto/ccp/sev-dev.c b/drivers/crypto/ccp/sev-dev.c
index 096f993974d1..362126453ef0 100644
--- a/drivers/crypto/ccp/sev-dev.c
+++ b/drivers/crypto/ccp/sev-dev.c
@@ -75,6 +75,10 @@ static bool psp_init_on_probe = true;
module_param(psp_init_on_probe, bool, 0444);
MODULE_PARM_DESC(psp_init_on_probe, " if true, the PSP will be initialized on module init. Else the PSP will be initialized on the first command requiring it");
+static bool rapl_disable;
+module_param(rapl_disable, bool, 0444);
+MODULE_PARM_DESC(rapl_disable, " if true, the RAPL_DIS bit will be set during INIT_EX if supported");
+
#if IS_ENABLED(CONFIG_PCI_TSM)
static bool sev_tio_enabled = true;
module_param_named(tio, sev_tio_enabled, bool, 0444);
@@ -1428,6 +1432,16 @@ static int __sev_snp_init_locked(int *error, unsigned int max_snp_asid)
data.max_snp_asid = max_snp_asid;
}
+ if (rapl_disable) {
+ if (sev->snp_feat_info_0.ecx & SNP_RAPL_DISABLE_SUPPORTED) {
+ data.rapl_dis = 1;
+ } else {
+ dev_info(sev->dev,
+ "SEV: RAPL_DIS requested, but not supported");
+ rapl_disable = false;
+ }
+ }
+
data.init_rmp = 1;
data.list_paddr_en = 1;
data.list_paddr = __psp_pa(snp_range_list);
--
2.53.0On Mon, Feb 23, 2026, Tycho Andersen wrote:
> From: "Tycho Andersen (AMD)" <tycho@kernel.org>
>
> The kernel allows setting the RAPL_DIS policy bit, but had no way to set
Please actually say what RAPL_DIS is and does, and explain why this is the
correct approach. I genuinely have no idea what the impact of this patch is,
(beyond disabling something, obviously).
> the RAPL_DIS bit during SNP_INIT_EX. Setting the policy bit would always
> result in:
>
> [ 898.840286] ccp 0000:a9:00.5: sev command 0xa0 failed (0x00000007)
>
> Allow setting the RAPL_DIS bit during SNP_INIT_EX via a module parameter.
> If the hardware does not support RAPL_DIS, log and disable the module
> parameter.
>
> Signed-off-by: Tycho Andersen (AMD) <tycho@kernel.org>
> ---
> drivers/crypto/ccp/sev-dev.c | 14 ++++++++++++++
> 1 file changed, 14 insertions(+)
>
> diff --git a/drivers/crypto/ccp/sev-dev.c b/drivers/crypto/ccp/sev-dev.c
> index 096f993974d1..362126453ef0 100644
> --- a/drivers/crypto/ccp/sev-dev.c
> +++ b/drivers/crypto/ccp/sev-dev.c
> @@ -75,6 +75,10 @@ static bool psp_init_on_probe = true;
> module_param(psp_init_on_probe, bool, 0444);
> MODULE_PARM_DESC(psp_init_on_probe, " if true, the PSP will be initialized on module init. Else the PSP will be initialized on the first command requiring it");
>
> +static bool rapl_disable;
> +module_param(rapl_disable, bool, 0444);
> +MODULE_PARM_DESC(rapl_disable, " if true, the RAPL_DIS bit will be set during INIT_EX if supported");
> +
> #if IS_ENABLED(CONFIG_PCI_TSM)
> static bool sev_tio_enabled = true;
> module_param_named(tio, sev_tio_enabled, bool, 0444);
> @@ -1428,6 +1432,16 @@ static int __sev_snp_init_locked(int *error, unsigned int max_snp_asid)
> data.max_snp_asid = max_snp_asid;
> }
>
> + if (rapl_disable) {
> + if (sev->snp_feat_info_0.ecx & SNP_RAPL_DISABLE_SUPPORTED) {
> + data.rapl_dis = 1;
> + } else {
> + dev_info(sev->dev,
> + "SEV: RAPL_DIS requested, but not supported");
> + rapl_disable = false;
> + }
> + }
> +
> data.init_rmp = 1;
> data.list_paddr_en = 1;
> data.list_paddr = __psp_pa(snp_range_list);
> --
> 2.53.0
>
On Mon, Feb 23, 2026 at 08:40:19AM -0800, Sean Christopherson wrote:
> On Mon, Feb 23, 2026, Tycho Andersen wrote:
> > From: "Tycho Andersen (AMD)" <tycho@kernel.org>
> >
> > The kernel allows setting the RAPL_DIS policy bit, but had no way to set
>
> Please actually say what RAPL_DIS is and does, and explain why this is the
> correct approach. I genuinely have no idea what the impact of this patch is,
> (beyond disabling something, obviously).
Sure, the easiest thing is probably to quote the firmware PDF:
Some processors support the Running Average Power Limit (RAPL)
feature which provides information about power utilization of
software. RAPL can be disabled using the RAPL_DIS flag in
SNP_INIT_EX to disable RAPL while SNP firmware is in the INIT
state. Guests may require that RAPL is disabled by using the
POLICY.RAPL_DIS guest policy flag.
I'll add this to the message in the next version.
I will also split out the RAPL_DIS stuff from the test fix for the
firmware update.
Tycho
On Mon, Feb 23, 2026, Tycho Andersen wrote: > On Mon, Feb 23, 2026 at 08:40:19AM -0800, Sean Christopherson wrote: > > On Mon, Feb 23, 2026, Tycho Andersen wrote: > > > From: "Tycho Andersen (AMD)" <tycho@kernel.org> > > > > > > The kernel allows setting the RAPL_DIS policy bit, but had no way to set > > > > Please actually say what RAPL_DIS is and does, and explain why this is the > > correct approach. I genuinely have no idea what the impact of this patch is, > > (beyond disabling something, obviously). > > Sure, the easiest thing is probably to quote the firmware PDF: > > Some processors support the Running Average Power Limit (RAPL) > feature which provides information about power utilization of > software. RAPL can be disabled using the RAPL_DIS flag in > SNP_INIT_EX to disable RAPL while SNP firmware is in the INIT > state. Guests may require that RAPL is disabled by using the > POLICY.RAPL_DIS guest policy flag. Ah, I assume this about disabling RAPL to mitigate a potential side channel? If so, please call that out in the changelog. And does this disable RAPL for _everything_? Or does it just disable RAPL for SNP VMs? If it's the former, then burying this in drivers/crypto/ccp/sev-dev.c feels wrong.
On Tue, Feb 24, 2026 at 09:50:11AM -0800, Sean Christopherson wrote: > On Mon, Feb 23, 2026, Tycho Andersen wrote: > > On Mon, Feb 23, 2026 at 08:40:19AM -0800, Sean Christopherson wrote: > > > On Mon, Feb 23, 2026, Tycho Andersen wrote: > > > > From: "Tycho Andersen (AMD)" <tycho@kernel.org> > > > > > > > > The kernel allows setting the RAPL_DIS policy bit, but had no way to set > > > > > > Please actually say what RAPL_DIS is and does, and explain why this is the > > > correct approach. I genuinely have no idea what the impact of this patch is, > > > (beyond disabling something, obviously). > > > > Sure, the easiest thing is probably to quote the firmware PDF: > > > > Some processors support the Running Average Power Limit (RAPL) > > feature which provides information about power utilization of > > software. RAPL can be disabled using the RAPL_DIS flag in > > SNP_INIT_EX to disable RAPL while SNP firmware is in the INIT > > state. Guests may require that RAPL is disabled by using the > > POLICY.RAPL_DIS guest policy flag. > > Ah, I assume this about disabling RAPL to mitigate a potential side channel? If > so, please call that out in the changelog. > > And does this disable RAPL for _everything_? Or does it just disable RAPL for > SNP VMs? If it's the former, then burying this in drivers/crypto/ccp/sev-dev.c > feels wrong. Presumably you're right on both counts, but I've asked our firmware team to clarify exactly what happens. I guess that means it should be kvm-amd.rapl_disable? Thanks, Tycho
© 2016 - 2026 Red Hat, Inc.