Public bug reported:

[SRU Justification]

[Impact]

Starting with the AH2020 Azure host build, Hyper-V is virtualizing some
registers that provide information about the CPU frequency. The
registers are read-only in a guest VM, so the guest can see the
frequency, but cannot make any modifications.

This feature also requires that the VM Configuration Version be 9.2 or
later, which means it needs to be a new VM type, such as the just
introduced Dv5/Ev5 series, and the new M832v2 VMs.

Within the Linux VM, the presence of the feature is indicated by the
“aperfmperf” flag in the “lscpu” flags output (or in the flags field in
/proc/cpuinfo).

It turns out there is a Linux kernel limitation when running on the new
Intel IceLake processors used for the Dv5/Ev5 series. Upstream commit
fbdc21e9b038 was added to provide IceLake support in the 5.14 kernel.

Microsoft has asked to backport fbdc21e9b038 commit to all supported
kernels.

[Test Plan]

Run Intel IceLake based VM and check the "aperfmperf" flag in the
"lscpu" flags output.

Without the patch the intel_pstate directory is missing from
/sys/devices/system/cpu/ and /sys/devices/system/cpu/cpufreq/ is empty.

[Where problems could occur]

* intel_pstate driver is always used on Intel IceLake based VMs without
checking for presence of "aperfmperf" CPU flag.

* In earlier (5.4 and 4.15) linux-azure kernels when intel_pstate driver
is used it is in "active" mode instead of "passive" one (as reported by
"cat /sys/devices/system/cpu/intel_pstate/status", also "cat
/sys/devices/system/cpu/cpufreq/policy0/scaling_driver" returns
"intel_pstate" instead of "intel_cpufreq" which is the expected behavior
when in "active" mode).

If a consistent behavior across all kernel versions is desired commit
33aa46f252c7 ("cpufreq: intel_pstate: Use passive mode by default
without HWP") from the upstream should probably also be backported.

* /sys/devices/system/cpu/cpufreq/policy*/scaling_{min,max}_freq files
can be modified and the values reported by kernel will no longer match
the values used by hardware.

[Other Info]

None.

** Affects: linux-azure (Ubuntu)
     Importance: Undecided
         Status: New

-- 
You received this bug notification because you are a member of Kernel
Packages, which is subscribed to linux-azure in Ubuntu.
https://bugs.launchpad.net/bugs/1952234

Title:
  linux-azure: add Icelake servers support in no-HWP mode to
  cpufreq/intel_pstate driver

Status in linux-azure package in Ubuntu:
  New

Bug description:
  [SRU Justification]

  [Impact]

  Starting with the AH2020 Azure host build, Hyper-V is virtualizing
  some registers that provide information about the CPU frequency. The
  registers are read-only in a guest VM, so the guest can see the
  frequency, but cannot make any modifications.

  This feature also requires that the VM Configuration Version be 9.2 or
  later, which means it needs to be a new VM type, such as the just
  introduced Dv5/Ev5 series, and the new M832v2 VMs.

  Within the Linux VM, the presence of the feature is indicated by the
  “aperfmperf” flag in the “lscpu” flags output (or in the flags field
  in /proc/cpuinfo).

  It turns out there is a Linux kernel limitation when running on the
  new Intel IceLake processors used for the Dv5/Ev5 series. Upstream
  commit fbdc21e9b038 was added to provide IceLake support in the 5.14
  kernel.

  Microsoft has asked to backport fbdc21e9b038 commit to all supported
  kernels.

  [Test Plan]

  Run Intel IceLake based VM and check the "aperfmperf" flag in the
  "lscpu" flags output.

  Without the patch the intel_pstate directory is missing from
  /sys/devices/system/cpu/ and /sys/devices/system/cpu/cpufreq/ is
  empty.

  [Where problems could occur]

  * intel_pstate driver is always used on Intel IceLake based VMs
  without checking for presence of "aperfmperf" CPU flag.

  * In earlier (5.4 and 4.15) linux-azure kernels when intel_pstate
  driver is used it is in "active" mode instead of "passive" one (as
  reported by "cat /sys/devices/system/cpu/intel_pstate/status", also
  "cat /sys/devices/system/cpu/cpufreq/policy0/scaling_driver" returns
  "intel_pstate" instead of "intel_cpufreq" which is the expected
  behavior when in "active" mode).

  If a consistent behavior across all kernel versions is desired commit
  33aa46f252c7 ("cpufreq: intel_pstate: Use passive mode by default
  without HWP") from the upstream should probably also be backported.

  * /sys/devices/system/cpu/cpufreq/policy*/scaling_{min,max}_freq files
  can be modified and the values reported by kernel will no longer match
  the values used by hardware.

  [Other Info]

  None.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/linux-azure/+bug/1952234/+subscriptions


-- 
Mailing list: https://launchpad.net/~kernel-packages
Post to     : kernel-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kernel-packages
More help   : https://help.launchpad.net/ListHelp

Reply via email to