Re: [PATCH] cpufreq/amd-pstate: Bail out early in virtual machines and don't warn

[Jason Andryuk <jason.andryuk@amd.com>]

On 2026-07-15 15:21, Rong Zhang wrote:
> Hi Borislav,
> 
> Thanks for reviewing the patch.
> 
> On Wed, 2026-07-15 at 11:04 -0700, Borislav Petkov wrote:
>> On Wed, Jul 15, 2026 at 12:46:24PM -0500, Mario Limonciello wrote:
>>> Conceptually this makes sense to me, but I would like some comments from
>>> others if this is the right way forward.
>>>
>>> Jason, Boris,
>>>
>>> comments please?
>>
>> We don't care if someone "passes-through a relatively new CPUID" - I am not
>> sure what that means -
>>
> 
> Sorry, typo here. I meant CPU model.
> 
> I usually boot a KVM with `qemu-system-x86_64 -accel kvm -cpu host
> <other_args...>' to test various patches. These messages is a bit
> disturbing to me as they are KERN_WARNING messages.
> 
> FYI, my device is Zen 5 based and always triggers both messages.
> 
> I can also reproduce both messages with `-cpu EPYC-Genoa' and `-cpu
> EPYC-Turin'. It's just due to how amd_cppc_supported() is implemented.
> 
>> but we won't patch the upstream kernel just because it
>> dumped an error message in the guest.
> 
> Well, the reason why I decided to send this is not only about how noisy
> it is, but also about the correctness.
> 
> The first messages says:
> 
>     The CPPC feature is supported but currently disabled by the BIOS.
>     Please enable it if your BIOS has the CPPC option.
> 
> The CPPC feature is neither supported in a KVM nor disabled by the VM's
> BIOS.
> 
> IIUC, it's disabled by kvm_cpu_cap_init(CPUID_8000_0008_EBX, ...), so
> the upstream kernel both disables it as a hypervisor and warns about it
> as a guest. What a paradox!
> 
> At least the first message is nonsense in this case and the paradox
> should really be fixed. If you prefer preserving the second message
> ("the _CPC object is not present in SBIOS or ACPI disabled") as an
> informative hint anyway, how about moving the virtualization check into
> amd_cppc_supported() to only mute the first one? ;-)

I think changing amd_cppc_supported() to return false for 
X86_FEATURE_HYPERVISOR makes sense and can remove the message.  The 
heuristic there doesn't seem relevant when virtualized.

With Xen, the Xen hypervisor itself controls CPPC.  dom0 
(xen_initial_domain()) doesn't need the amd-pstate driver.

Regards,
Jason