Re: [Xen-devel] some thoughts about merlot{0|1} issues [was: Re: [xen-unstable test] 102522: tolerable FAIL - PUSHED]

[Andrew Cooper <andrew.cooper3@xxxxxxxxxx>]

On 28/11/16 15:16, Konrad Rzeszutek Wilk wrote:
> On Mon, Nov 28, 2016 at 08:48:30AM -0500, Boris Ostrovsky wrote:
>> On 11/24/2016 10:31 AM, Jan Beulich wrote:
>>>>>> On 24.11.16 at 16:14, <dario.faggioli@xxxxxxxxxx> wrote:
>>>> When dumping ACPI C states, here's how things look like for _all_ CPUs:
>>>> Nov 23 13:13:00.382134 (XEN) ==cpu3==
>>>> Nov 23 13:13:00.382157 (XEN) active state:         C-1
>>>> Nov 23 13:13:00.390096 (XEN) max_cstate:           C7
>>>> Nov 23 13:13:00.390125 (XEN) states:
>>>> Nov 23 13:13:00.390148 (XEN)     C1:       type[C1] latency[000] 
>>>> usage[00000000] method[ HALT] duration[0]
>>>> Nov 23 13:13:00.398055 (XEN)     C0:       usage[00000000] 
>>>> duration[4229118701384]
>>>> Nov 23 13:13:00.398090 (XEN) PC2[0] PC3[0] PC6[0] PC7[0]
>>>> Nov 23 13:13:00.406088 (XEN) CC3[0] CC6[0] CC7[0]
>>>>
>>>> And I checked other runs, and it's the same everywhere.
>>>>
>>>> I remember that Jan suggested trying to pass max_cstate=1 to Xen at
>>>> boot. I was about to ask Ian to do that for this host, but it looks
>>>> like we're using only C0 and C1 already anyway.
>>> This indeed looks surprising for a half way modern system - is the
>>> BIOS perhaps limiting C-states (maybe instructed to via BIOS setup)?
>>
>> IIRC some BIOSes indeed provided an option to disable C2. Dumping SSDT
>> would tell us whether C2 is there is BIOS is not accessible.
> Keep in mind that not all C states are exposed if MWAIT is not exposed
> to dom0 (see xen_check_mwait in arch/x86/xen/enlighten.c).
>
> I recall some emails from Andrew about the CPU faulting and his CPUID
> patches inhibiting this but it may very well be fixed?

merlot is AMD hardware, so no faulting.

Also, Xen purposefully leaks EIST into the control domain kernel to work
around that particular Linux bug.

~Andrew

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
https://lists.xen.org/xen-devel