Re: dom0 LInux 5.8-rc5 kernel failing to initialize cooling maps for Allwinner H6 SoC

[Alejandro <alejandro.gonzalez.correo@xxxxxxxxx>]

Hello,

El dom., 26 jul. 2020 a las 22:25, André Przywara
(<andre.przywara@xxxxxxx>) escribió:
> So this was actually my first thought: The firmware (U-Boot SPL) sets up
> some basic CPU frequency (888 MHz for H6 [1]), which is known to never
> overheat the chip, even under full load. So any concern from your side
> about the board or SoC overheating could be dismissed, with the current
> mainline code, at least. However you lose the full speed, by quite a
> margin on the H6 (on the A64 it's only 816 vs 1200(ish) MHz).
> However, without the clock entries in the CPU node, the frequency would
> never be changed by Dom0 anyway (nor by Xen, which doesn't even know how
> to do this).
> So from a practical point of view: unless you hack Xen to pass on more
> cpu node properties, you are stuck at 888 MHz anyway, and don't need to
> worry about overheating.
Thank you. Knowing that at least it won't overheat is a relief. But
the performance definitely suffers from the current situation, and
quite a bit. I'm thinking about using KVM instead: even if it does
less paravirtualization of guests, I'm sure that the ability to use
the maximum frequency of the CPU would offset the additional overhead,
and in general offer better performance. But with KVM I lose the
ability to have individual domU's dedicated to some device driver,
which is a nice thing to have from a security standpoint.

> Now if you would pass on the CPU clock frequency control to Dom0, you
> run into more issues: the Linux governors would probably try to setup
> both frequency and voltage based on load, BUT this would be Dom0's bogus
> perception of the actual system load. Even with pinned Dom0 vCPUs, a
> busy system might spend most of its CPU time in DomU VCPUs, which
> probably makes it look mostly idle in Dom0. Using a fixed governor
> (performance) would avoid this, at the cost of running full speed all of
> the time, probably needlessly.
>
> So fixing the CPU clocking issue is more complex and requires more
> ground work in Xen first, probably involving some enlightenend Dom0
> drivers as well. I didn't follow latest developments in this area, nor
> do I remember x86's answer to this, but it's not something easy, I would
> presume.
I understand, thanks :). I know that recent Intel CPUs (from Sandy
Bridge onwards) use P-states to manage frequencies, and even have a
mode of operation that lets the CPU select the P-states by itself. On
older processors, Xen can probably rely on ACPI data to do the
frequency scaling. But the most similar "standard thing" that my board
has, a AR100 coprocessor that with the (work in progress) Crust
firmware can be used with SCMI, doesn't even seem to support the use
case of changing CPU frequency... and SCMI is the most promising
approach for adding DVFS support in Xen for ARM, according to this
previous work: 
https://www.slideshare.net/xen_com_mgr/xpdds18-cpufreq-in-xen-on-arm-oleksandr-tyshchenko-epam-systems

> Alejandro: can you try to measure the actual CPU frequency in Dom0?
> Maybe some easy benchmark? "mhz" from lmbench does a great job in
> telling you the actual frequency, just by clever measurement. But any
> other CPU bound benchmark would do, if you compare bare metal Linux vs.
> Dom0.
I have measured the CPU frequency in Dom0 using lmbench several times
and it seems to be stuck at 888 MHz, the frequency set by U-Boot.
Overall, the system feels more sluggish than when using bare Linux,
too. It doesn't matter if I apply the "hacky fix" I mentioned before
or not.

> Also, does cpufreq come up in Dom0 at all? Can you select governors and
> frequencies?
It doesn't come up, and no sysfs entries are created for cpufreq. With
the "fix", the kernel prints an error message complaining that it
couldn't probe cpufreq-dt, but it still doesn't come up, and sysfs
entries for cpufreq aren't created either.