Re: [PATCH v2 3/4] KVM: SEV: Add the kvm-amd.rapl_disable module parameter

[Tycho Andersen <tycho@kernel.org>]

On Tue, Apr 28, 2026 at 09:46:42AM -0700, Sean Christopherson wrote:
> On Tue, Apr 28, 2026, Tom Lendacky wrote:
> > On 4/28/26 10:53, Sean Christopherson wrote:
> > > On Tue, Apr 28, 2026, Tycho Andersen wrote:
> > >> On Mon, Apr 27, 2026 at 02:20:10PM -0700, Sean Christopherson wrote:
> > >>> I'm pretty sure I said this earlier: KVM absolutely should not be able to disable
> > >>> RAPL for the entire system.  That needs to be a power management thing.
> > >>
> > >> You definitely noted "not CCP", I don't think I quite understood what
> > >> that meant though:
> > >> https://lore.kernel.org/all/aZ86BZWi-GLiHvmt@tycho.pizza/
> > >>
> > >> I'm a little worried that putting it in power management will generate
> > >> some weird dependencies, or weakref symbols that can't change things
> > >> if they are loaded independently of kvm_amd or something. But let me
> > >> see what I can come up with.
> > > 
> > > Ugh, and it's not even powerman per se, it's actually a module in perf.  Oof.
> > > 
> > > I 100% agree it'll be tricky, but I also stand by comments that neither the CCP
> > > driver or KVM should be allowed to silently pull the rug out from under the RAPL
> > > module.
> > 
> > Maybe something that can be added to the current sev= kernel command line
> > parameter, e.g. sev=norapl, or such?
> 
> Yeah.  The only question I have is if we expect end users to want to disable RAPL
> at runtime.  If so, then we probably want a sysfs knob or something.
> 
> However, letting RAPL be toggled on/off will introduce some amount of complexity,
> as the kernel would need to negotiate/coordinate with the RAPL perf module and
> with the CPP driver to ensure RAPL stays in the "correct" state.  E.g. if the
> perf module is loaded, then RAPL is effectively pinned "on".  And if SNP has been
> initialized with RAPL_DIS, then RAPL is effectively pinned "off".  Blech.
> 
> > Maybe even with a kernel config option for a default value?
> 
> Probably overkill?
> 
> > On SNP_SHUTDOWN it will be re-enabled if it was disabled.
> 
> Stating the obvious, if we do this, we open the can of worms I described above.

Unfortunately that's how the firmware works and since we do a shutdown
on module unload, if you have ccp=m this is the behavior.

Maybe it makes sense to go the other way: have perf look for a ccp
symbol that's loaded that says whether RAPL is usable or not, and
refuse to allow access to the counters if it is? But it looks like
there are several UAPIs for this (perf, /dev/amd-hsmp-*, sysfs), so
it's not just one place, which is also ugly.

> > >>> KVM then needs to communicate (and enforce?) the policy to
> > >>> userspace.
> > >>
> > >> KVM doesn't need to enforce anything, the SEV firmware will generate a
> > >> launch error for policy violation if it's not supported.
> > >>
> > >> For communicating to userspace if it's not a kvm module parameter, one
> > >> option is to mask it off in sev_get_snp_supported_policy() if it was
> > 
> > Did you mean sev_get_snp_policy_bits() or were you referring to the KVM
> > ioctl() for retrieving them?

I was thinking of the ioctl() for retrieving them, but doing the
masking in sev_get_snp_policy_bits() since it would be able to
remember whether RAPL_DIS was set or not. Of course I merged the two
in my head when typing the sentence :)

> > >> initialized without the support. Then it'll be visible via
> > >> KVM_X86_SNP_POLICY_BITS.
> > > 
> > > Ya, this is what I was envisioning.
> > 
> > It's still a valid policy bit (if supported by the platform), so I don't
> > think masking it off is appropriate.
> 
> But it's not fully supported, no?  I.e. won't the VM fail if it requests RAPL_DIS?
> 
> Ooh, presumably the subtle difference is that on a platform without RAPL_DIS at
> all, the VM will successfully launch and thus could run with RAPL enabled even
> if the VM requested RAPL_DIS?

I haven't tested this, but I would hope what you describe an error. I
think Tom means it's supported by the architecture, it just needs to
be enabled via reconfiguration.

Tycho