From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-pl1-f201.google.com (mail-pl1-f201.google.com [209.85.214.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id BB2FD3002D1 for ; Tue, 28 Apr 2026 16:46:44 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.214.201 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1777394806; cv=none; b=K1R+GxtB1mhEK4oLWgF65FlESKx8GwNN2mfnUR/cqLIa/mWO5S23NgCDnNRhkulYLnB2pkyE5EqjQedclyU1stql4pKgNp3m0XTZcPpnYGj3uPKtW5KL98IPvigBNFe3YofFUcRchPwt0SsYtalWAnVlUph+Hi27oGrrf6ED6Aw= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1777394806; c=relaxed/simple; bh=02Ll0yphJszxQQ3HWl4fGFlC3mEDZ3rgtgF4T/gAhdc=; h=Date:In-Reply-To:Mime-Version:References:Message-ID:Subject:From: To:Cc:Content-Type; b=hXoWMCjyU4lHsYIEClxoJ7Ytg54qnJ3M7NgUIjwgzr4XgXBWSZUDYVEQTC97sfxpd0Kt2otj6Jexd6HzAJJyQVDhFoL7xCZffnCrAbqGRX8xGexr68+mMCPKBFhLc+gG54U1tBWpKxjCYPv5wdroMJq/M2DouYh7kdgNF0Gc4ws= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=reject dis=none) header.from=google.com; spf=pass smtp.mailfrom=flex--seanjc.bounces.google.com; dkim=pass (2048-bit key) header.d=google.com header.i=@google.com header.b=hVOGYrQN; arc=none smtp.client-ip=209.85.214.201 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=reject dis=none) header.from=google.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=flex--seanjc.bounces.google.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=google.com header.i=@google.com header.b="hVOGYrQN" Received: by mail-pl1-f201.google.com with SMTP id d9443c01a7336-2b2e06219cbso141149295ad.3 for ; Tue, 28 Apr 2026 09:46:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20251104; t=1777394804; x=1777999604; darn=vger.kernel.org; h=cc:to:from:subject:message-id:references:mime-version:in-reply-to :date:from:to:cc:subject:date:message-id:reply-to; bh=kEkPC/bbmwo82zT+9sMdK7tO+DGFA2UM3xH5lqU9uE8=; b=hVOGYrQNYg6P/8G4eKUVwhdKyjDwMXiB5eQ9087qmJI1lyCBmM3OseIjfS/q8VVJhg ADPRjMrlOxT7EK8MTZ0tsjcq+JAh5WfbU2+jM8tBl0vXBVwES8+6B3/MJQqSvaX6pV4L ajb7UdDtFQFgU0N5oh1FdXQ5OZTXkyl4+PCjyi1DmUtfDM5J8jO5JLczp1veitgmszfq +tjYUHOVCMQnfd8a6CynmoNLgQ11ILWXuTJhfF9oG8KlPEpj4qPBDTXtv6XVffqdC9rS weSEqTD3S6WOWRgfS5xjI9OJrm5otHK7lh3vepR/DGJufXkg77k+0GUwxN2NL1eC79rN eI1Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1777394804; x=1777999604; h=cc:to:from:subject:message-id:references:mime-version:in-reply-to :date:x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=kEkPC/bbmwo82zT+9sMdK7tO+DGFA2UM3xH5lqU9uE8=; b=gTDOGDYfP7NDOilDwVvJVx0DA6N/N+2IQ5pP92H5dQA6h3MXiM9Z1pDjC69kaWfHfa /WMFKFBdamwzSvEIpIFZ8AQ9rLy0mP0Oc0xRMXVcNCoMrutv1syIvZNZqVYalSFLCx9v DLFZzIcw5c9zjPiM0BZbjfefbwzrzJh8WhiT3hM4tYV3U7FIHnZFOI1a3m7YKyWlWdyP 8kHDH27xENnY5Y29CqbvW9ilti16CN3bbZt199X0z3yWiWaM7OzEB9OtoZlQ37AQ/K+/ CW8BltXF8ea4iuKygdGvds68tcRlKnyXoEmKeF0sKf66+iDGUcr0/Uyl2FtVpVYkkx5x 8A0A== X-Forwarded-Encrypted: i=1; AFNElJ+efrKITCCTsZtWAPeTyPBAl0k4xjATKIydpczOWKGrW4ASaAeTfh5vO7tZvrqWWyHS0veR3lHTPhU=@vger.kernel.org X-Gm-Message-State: AOJu0YzKPeRmWgyrhp6Xz15YvjozVY+thvc2mwdY4uR506sbX7AFrE1M SMorfJRTDQGQlYMgGEspgNVAQs0gqAXyoZTZL51yEfFwmpVEZdkacW5UiuBnltuLuvIKJq2Py8B CFyCPVQ== X-Received: from pgbcz1.prod.google.com ([2002:a05:6a02:2301:b0:c61:2d0c:40bf]) (user=seanjc job=prod-delivery.src-stubby-dispatcher) by 2002:a05:6a20:6a1a:b0:3a3:5726:7e39 with SMTP id adf61e73a8af0-3a3af426340mr463737637.23.1777394803747; Tue, 28 Apr 2026 09:46:43 -0700 (PDT) Date: Tue, 28 Apr 2026 09:46:42 -0700 In-Reply-To: <20f94bed-2843-44ab-877c-3e68bd4314f8@amd.com> Precedence: bulk X-Mailing-List: linux-doc@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: Mime-Version: 1.0 References: <20260427204847.112899-1-tycho@kernel.org> <20260427204847.112899-4-tycho@kernel.org> <20f94bed-2843-44ab-877c-3e68bd4314f8@amd.com> Message-ID: Subject: Re: [PATCH v2 3/4] KVM: SEV: Add the kvm-amd.rapl_disable module parameter From: Sean Christopherson To: Tom Lendacky Cc: Tycho Andersen , Ashish Kalra , John Allen , Herbert Xu , "David S. Miller" , Jonathan Corbet , Shuah Khan , Paolo Bonzini , Thomas Gleixner , Ingo Molnar , Borislav Petkov , Dave Hansen , x86@kernel.org, "H. Peter Anvin" , Shuah Khan , linux-crypto@vger.kernel.org, linux-kernel@vger.kernel.org, Kim Phillips , Alexey Kardashevskiy , Nikunj A Dadhania , Andrew Morton , Randy Dunlap , Dapeng Mi , Kees Cook , Marco Elver , Jakub Kicinski , Li RongQing , Eric Biggers , "Paul E. McKenney" , linux-doc@vger.kernel.org, kvm@vger.kernel.org, linux-kselftest@vger.kernel.org Content-Type: text/plain; charset="us-ascii" 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. > >>> 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? > > >> 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?