From mboxrd@z Thu Jan 1 00:00:00 1970 From: "Jan Beulich" Subject: Re: expose MWAIT to dom0 Date: Mon, 15 Aug 2011 09:02:29 +0100 Message-ID: <4E48EEB50200007800051398@nat28.tlf.novell.com> References: <625BA99ED14B2D499DC4E29D8138F15062D2E80C3A@shsmsx502.ccr.corp.intel.com> Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: quoted-printable Return-path: In-Reply-To: <625BA99ED14B2D499DC4E29D8138F15062D2E80C3A@shsmsx502.ccr.corp.intel.com> Content-Disposition: inline List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com To: Kevin Tian Cc: Yang Z Zhang , "xen-devel@lists.xensource.com" , Keir Fraser , Gang Wei List-Id: xen-devel@lists.xenproject.org >>> On 15.08.11 at 07:35, "Tian, Kevin" wrote: > There're basically two methods to enter a given C-state: legacy (hlt + = I/O=20 > read), > and native(using mwait). MWAIT is always preferred when both underlying = CPU > and OS support, which is a more efficient way to conduct C-state = transition. >=20 > Xen PM relies on Dom0 to parse ACPI Cx/Px information, which involves = one > step to notify BIOS about a set of capabilities supported by OSPM. = One=20 > capability > is about mwait support, which if true ACPI Cx entry contains entry=20 > parameters=20 > for mwait, or else I/O port information is provided. Xen PM later = decides=20 > entry > method (i/o or mwait) based on parsed ACPI information from dom0. >=20 > However Xen doesn't expose MWAIT capability to dom0 due to changeset = 17573: >=20 > This then brings a problem to Dom0 which thinks underlying CPU > doesn't report mwait, and thus notify BIOS to use old I/O based method. >=20 > Later a trick is integrated in Jeremy's pvops tree: >=20 > --- a/arch/x86/kernel/acpi/processor.c > +++ b/arch/x86/kernel/acpi/processor.c > @@ -60,7 +60,7 @@ static void init_intel_pdc(struct acpi_processor = *pr,=20 > struct cpuinfo_x86 *c) > /* > * If mwait/monitor is unsupported, C2/C3_FFH will be disabled > */ > - if (!cpu_has(c, X86_FEATURE_MWAIT)) > + if (!cpu_has(c, X86_FEATURE_MWAIT) && !xen_initial_domain()) > buf[2] &=3D ~(ACPI_PDC_C_C2C3_FFH); > =20 > obj->type =3D ACPI_TYPE_BUFFER; >=20 > Above trick is ugly and error-prone, since it always enable mwait = regardless=20 > of actual CPU capability. 3.x (and later 2.6.3x) don't look at the CPUID flag anymore, they just check boot_option_idle_override, which is being controlled from the command line or enforced for some particular systems based on DMI data. > It's unlikely to make into upstream, and also get lost in > into some distro such as SLES11. We can certainly fix it there. Jan