cpufreq drivers on T480S not working

[Milky]

System is T480s with i5-8250U and Libreboot running R4.2. I've tested the following 4 configurations: 1. Default 2. `GRUB_CMDLINE_XEN_DEFAULT="cpufreq=xen:hwp"` as per [0](https://github.com/QubesOS/qubes-issues/issues/4604#issuecomment-1472183538) 3. `GRUB_CMDLINE_XEN_DEFAULT="cpufreq=dom0-kernel dom0_vcpus_pin"` as per [1](https://wiki.xenproject.org/wiki/Xen_power_management#Domain0_based_cpufreq) 4. `GRUB_CMDLINE_XEN_DEFAULT="cpufreq=xen:performance"` as per [2](https://xenbits.xen.org/docs/unstable/misc/xen-command-line.html#cpufreq) In all cases, `cat /proc/cpuinfo` reports the fixed value `cpu Mhz: 1800`, confirmed also using `dmidecode`. `sysbench` in an AppVM with max vcpus consistently reports about 1600 events per second, while the dom0 stats in the previous commands remain unchanged. Furthermore, the following commands were also checked in configurations 1 and 2: ``` # xenpm get-cpufreq-para [CPU0] failed to get cpufreq parameter <...> # xenpm get-cpufreq-states <no output> # ls /sys/devices/system/cpu/intel_pstate <no such file> # sudo lsmod | grep 'cpufreq\|xen_acpi_processor' <no output> # modprobe xen_acpi_processor <no such device> ``` For configurations 2, 3, 4 the complete output of `xl dmesg` is here: [3](https://0x0.st/KC5L.txt). Weirdly, in configurations 2 and 4, it reports: `Using HWP for cpufreq`. To rule out causes independent of Xen/Qubes, I booted using a Debian Live image. `sysbench` consistently reported 4000 events per second, while `/sys/cpuinfo` reliably showed a jump from 900Mhz to 3.4GHz. In conclusion, only under Xen, something seems to block the scaling drivers from working on my system. To me, this seems like a bug. However when I posted about it on Github issue [#4604](https://github.com/QubesOS/qubes-issues/issues/4604#issuecomment-3636704806), I was repeatedly told that the Github forum wasn't intended for this and so far there was no other engagement from the dev team. At the same time, my situation seems significantly different from what others are reporting in that thread, so I'm not sure if I should maybe bother opening a separate issue.