Page MenuHomeFreeBSD

hwpstate_amd: Expose node as much as possible
ClosedPublic

Authored by aokblast on Mar 1 2026, 4:54 PM.
Tags
None
Referenced Files
F151966128: D55606.id173971.diff
Sat, Apr 11, 8:02 PM
F151966124: D55606.id173617.diff
Sat, Apr 11, 8:02 PM
F151966122: D55606.id172975.diff
Sat, Apr 11, 8:02 PM
F151966116: D55606.id172972.diff
Sat, Apr 11, 8:02 PM
F151966111: D55606.id.diff
Sat, Apr 11, 8:02 PM
Unknown Object (File)
Sat, Apr 11, 11:33 AM
Unknown Object (File)
Sat, Apr 11, 12:24 AM
Unknown Object (File)
Wed, Apr 8, 9:52 AM
Subscribers

Diff Detail

Repository
rG FreeBSD src repository
Lint
Lint Not Applicable
Unit
Tests Not Applicable

Event Timeline

olce requested changes to this revision.Mar 9 2026, 9:34 AM
olce added a subscriber: olce.

Changes themselves look good, except for one mistake (wrong MSR).

We are missing something both to ease configuration and to minimize the disruption due to breaking backwards compatibility: A knob allowing to change the setting of all CPUs at once, to be below dev.hwpstate_amd (instead of under dev.hwpstate_amd.X where X is the CPU number). (That's for a separate revision/commit.) I have been wanting to have a similar change for CPPC, in order to retire machdep.hwpstate_pkg_ctrl for hwpstate_amd(4) (and we would obsolete it for hwpstate_intel(4) by having something similar there).

sys/x86/cpufreq/hwpstate_amd.c
605

Wrong MSR here.

685–686

This code to read the status could be factored out (there is another such call in hwpstate_goto_pstate()).

1127

Style.

1152

msrs seems confusing as a name. Open to other suggestions.

This revision now requires changes to proceed.Mar 9 2026, 9:34 AM

Some additional tiny changes and this is good to go.

sys/x86/cpufreq/hwpstate_amd.c
555

When using MSR_OP_READ without MSR_OP_SAFE, only 0 can be returned by x86_msr_op(), so I suggest to just change the return type of the function, and also convert the result of the latter explicitly to void with a comment explaining why.

558–559

As explained above (and please add a small comment explaining the why; may be a copy of the above inline comment).

562–567

Same here.

Looks good.

My previous herald comment perhaps was unclear. I was fearing that this change alone would break powerd(8), because it only operates on dev.cpu.0.freq (first CPU only). While discussing this in person at AsiaBSDCon, though, you pointed out that currently, cpufreq(4) will just call CPUFREQ_SET() on all CPUs (from cpufreq_curr_sysctl()), so in effect powerd(8) should not be affected at this stage (but would be after D55614).

This revision is now accepted and ready to land.Thu, Mar 26, 2:26 PM