Re: Questions about Cx and Px state uploading from dom0

[Elliott Mitchell <ehem+xen@xxxxxxx>]

On Wed, Mar 23, 2022 at 09:54:24AM +0100, Roger Pau Monn?? wrote:
> 
> 2. When uploading Px states, what's the meaning of the shared_type
> field in xen_processor_performance?  I've looked at the usage of the
> field by Xen, and first of all it seems to be a layering violation
> because the values set in the field (CPUFREQ_SHARED_TYPE_*) are not
> exposed as part of the public interface.  This all works for Linux
> because the same values are used by Xen and the Linux kernel.
> Secondly, this is not part of the data fetched from ACPI AFAICT, so
> I'm unsure how the value should be calculated.  I also wonder whether
> this couldn't be done by Xen itself from the uploaded Px data (but
> without knowing exactly how the value should be calculated it's hard
> to tell).

This would account for some of the behavior with Xen and Linux.  The
Xen C-state support doesn't seem to be in a stable state.  I've seen the
level of functionality vary by version of Xen and Linux.

In particular C-states appear to be a problem.  Enabling C-states besides
C0 appears to require a corresponding Domain 0 vCPU.  If Domain 0 has
fewer vCPUs than physical cores, C2 will be unavailable on some cores.
Also, C2 is only available with some combinations of Xen and Linux.

This isn't an issue for datacenters where idle processors are wasted
money, but for smaller systems reduced power consumption is a good thing.
Hypervisors are moving onto smaller and smaller systems, so power
consumption is a bigger issue now.


-- 
(\___(\___(\______          --=> 8-) EHM <=--          ______/)___/)___/)
 \BS (    |         ehem+sigmsg@xxxxxxx  PGP 87145445         |    )   /
  \_CS\   |  _____  -O #include <stddisclaimer.h> O-   _____  |   /  _/
8A19\___\_|_/58D2 7E3D DDF4 7BA6 <-PGP-> 41D1 B375 37D0 8714\_|_/___/5445