-
-
Notifications
You must be signed in to change notification settings - Fork 52
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Include support for Intel HWP #158
Conversation
PipelineRetry |
openQArun |
PipelineRetry |
1 similar comment
PipelineRetry |
+ uint8_t maximum; | ||
+ uint8_t desired; | ||
+ uint8_t energy_perf; | ||
+}; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Not sure if padding is an issue, but if it is:
+}; | |
+ uint16_t padding; | |
+}; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@DemiMarie I don't think padding matters - hwp_drv_data is a xen-internal struct to track HWP capabilities and current settings.
@marmarek It looks like you picked up v1 of my patchset. My v2 addressed some feedback, and dropped the "fast MSR" support. There aren't too many changes though. The 0634-cpufreq-Add-Hardware-P-State-HWP-driver.patch v1 commit message says "it hardcodes the default 0x80 (out of 0x0-0xff) energy/performance preference.", but the v2 message correctly states "It will run with the default values, which should be the default 0x80 (out of 0x0-0xff) energy/performance preference." That is, it just uses the current values the system booted with unless they are changed by the user.
https://lore.kernel.org/xen-devel/[email protected]/#T
I am hoping to resubmit a v3 for upstream after I take care of some other pending work.
openQArun |
Thanks for the comment @jandryuk . I'm not sure how I missed v2... Anyway, I tried now, and I got a panic on boot :/ |
Ok, that was easy, missing |
I tried |
Hardware-managed P-states (when supported) results significantly smaller power consumption according to some user reports. Fixes QubesOS/qubes-issues#4604
Whoops, sorry about the missing cf_check.
I'll add more checking around setting the governor. Thanks for testing.
…On Wed, Feb 1, 2023, 3:51 PM Marek Marczykowski-Górecki < ***@***.***> wrote:
I tried xenpm set-scaling-governor hwp-internal, when booted without
cpufreq=xen:hwp. I don't think it's supposed to work, but it seemingly
succeeded. And now xenpm get-cpufreq-para fails.
—
Reply to this email directly, view it on GitHub
<#158 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AAOKZP5OO3HVZOC7O4OTNFDWVLEEHANCNFSM6AAAAAAUKA3E6U>
.
You are receiving this because you were mentioned.Message ID:
***@***.***>
|
openQArun |
PipelineRetry |
openQArun |
+ | ||
+ if ( boot_cpu_data.cpuid_level < 0x16 ) | ||
+ { | ||
+ hwp_info("HWP disabled: cpuid_level %x < 0x16 lacks CPU freq info\n", |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@jandryuk 0x%x
?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yes, good catch. Thanks. I'll also change the cpuid_level printing a few lines up from %u
to %#x
for consistency.
Hardware-managed P-states (when supported) results significantly smaller
power consumption according to some user reports.
Fixes QubesOS/qubes-issues#4604
@jandryuk thanks for making the patches (2 years ago...)!
I made some minor changes, especially:
no reliable discovery method on others