Re: S0ix support in Xen

[Jan Beulich <jbeulich@xxxxxxxx>]

On 27.02.2023 12:48, Simon Gaiser wrote:
> PIT timer: During some previous private discussion it was mentioned that
> the PIT timer that Xen initializes for IO-APIC testing prevents S0ix
> residency and therefore that part needs to be reworked. But if I'm
> reading the current code correctly Xen can already use the HPET timer
> instead, either with an automatic fallback if PIT is unavailable or by
> forcing it via hpet=legacy-replacement=1. Looking at the rest I think
> the PIT isn't used if Xen finds another clocksource. Did I miss
> something?

I think the concern was with calibrating the APIC clock against PIT,
but as you say that connection has been cut. So I think there's no
prereq work left there; Andrew may prove me wrong, though.

> mwait idle driver: While mwait-idle.c share a lot of code with Linux's
> intel_idle.c and the imported code seems to have been updated (for
> example for Alder Lake) it only supports the CPUs with hardcoded
> cstates. Linux's code also has a code path to read the cstate config
> from ACPI if the driver doesn't has a hard coded config for the model.
> This is needed for example for Tiger Lake. For my current testing I
> added the values the Linux code reads from ACPI by hand. But that's of
> course no proper solution. How should this be handled in Xen (IIUC some
> ACPI things are handled by Xen and some by dom0)?

Well, there's first of all some lack of understanding on my part: It
hasn't become clear to me why Linux now has two CPU idle drivers
consuming ACPI data (intel_idle and the purely ACPI-based one). If
two are really needed, then I guess mwait-idle would need extending
to also consume data passed up from Dom0, just like the ACPI-only
driver in Xen does (and which doesn't do anything until such data
was supplied).

> I'm not sure yet is what else in Xen needs to learn about S0ix. Running
> domains need to be halted, that can be handled by the toolstack. What
> other Xen internal things need to be aware of S0ix? Like avoiding
> unnecessary timer wakeups or similar. That's currently my biggest
> unknown and it would be great if someone with more insight and overview
> could give some hints here.

I didn't think the higher-level-software side of things was different
from S3. Instead I thought it's merely a matter of different
interaction with hardware that's needed (which, as per above, includes
avoiding certain things, i.e. in particular the PIT).

Jan