On 2/26/19 10:37 AM, Jan Beulich wrote: >>>> On 26.02.19 at 17:25, <brian.wo...@amd.com> wrote: >> Correct me if I'm wrong, but the Xen's acpi-idle implementation is >> dependent on dom0 using a AML interpreter and then giving that data back >> to Xen. I've heard that this doesn't always work correctly on PV dom0s >> and doesn't work at all on PVH dom0s. > > For C2 and deeper (using entering methods other than HLT) - yes. > The use of HLT is the default with the assumption that this will put > the system in C1 (i.e. with a pretty low wakeup latency); see > default_idle(), cpuidle_init_cpu(), and acpi_idle_do_entry(). > > Jan >
Well, assuming C2 is enabled (which I was assume is the default case), HLT roughly puts the processor in C2 rather than C1. On my test system, the debug console output for the cx tables only output HLT for C1 (which is wrong). Rather than depending on dom0, which is shaky, and not having an AML interpreter, it seems the best solution is to hardcode the values in like Intel does. If Xen had an AML interpreter, I'd agree doing things differently (reading in the ACPI tables) would be best. But given the resources Xen has at the moment, this seems like the safest solution and is better than using HLT (which is C2 assuming it's enabled) as the default idle method like Xen is using now. It comes down to sometimes (when C2 is diabled in BIOS) using C1 thinking it's C2, or without the patches in the common case using C2 thinking it's C1. Brian _______________________________________________ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
