>>> On 28.11.16 at 17:08, <andrew.coop...@citrix.com> wrote: > 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.faggi...@citrix.com> 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.
Isn't EIST an Intel-only thing? Jan _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel