[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

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().
> 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.

Xen-devel mailing list



Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.