Re: [Xen-devel] [PATCH 0/3] mwait support for AMD processors

["Jan Beulich" <JBeulich@xxxxxxxx>]

>>> On 26.02.19 at 17:54, <Brian.Woods@xxxxxxx> wrote:
> On 2/26/19 10:37 AM, Jan Beulich wrote:
>>>>> On 26.02.19 at 17:25, <Brian.Woods@xxxxxxx> 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().
> 
> 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.

So in one of our idle routines, how would one go about entering
C1 or C2 depending on wakeup latency requirements? I'm having a
hard time seeing how HLT can be used for both (without a reboot
cycle and a BIOS option change in between). Yet if there's only
one state that can be entered, then it's merely cosmetic whether
it gets called C1 or C2 in the debug output.

Anyway - I guess we need to continue this discussion (if necessary)
once I got around to actually look at the patches.

Jan



_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxxx
https://lists.xenproject.org/mailman/listinfo/xen-devel