RE: [Xen-devel] expose MWAIT to dom0

["Tian, Kevin" <kevin.tian@xxxxxxxxx>]

> From: Jan Beulich [mailto:JBeulich@xxxxxxxxxx]
> Sent: Monday, August 15, 2011 6:29 PM
> 
> >>> On 15.08.11 at 10:09, "Tian, Kevin" <kevin.tian@xxxxxxxxx> wrote:
> >>  From: Jan Beulich [mailto:JBeulich@xxxxxxxxxx]
> >> >>> On 15.08.11 at 07:35, "Tian, Kevin" <kevin.tian@xxxxxxxxx> wrote:
> >> > It's unlikely to make into upstream, and also get lost in
> >> > into some distro such as SLES11.
> >>
> >> We can certainly fix it there.
> >>
> >
> > that'd be great. I/O method has observable impact on power efficiency,
> > and the fix would be very welcomed. :-)
> 
> While the change is simple to do and works, I'm somewhat concerned

Current change mentioned above is not safe, which always enables mwait
support w/o knowledge about underlying presence. But new processors
all have mwait support, so this may not be big problem.

> that while improving the situation on CPUs that support the break-on-
> interrupt extension to mwait, it would result in C2/C3 not being usable
> at all on CPUs that don't (but support mwait in its simpler form and
> have ACPI tables specifying FFH as address space id). Is that only a
> theoretical concern (i.e. is there an implicit guarantee that for other
> than C1 FFH wouldn't be specified without that extension being
> available)? I thinks it's a practical one, or otherwise there wouldn't
> be a point in removing the ACPI_PDC_C_C2C3_FFH bit prior to _PDC
> evaluation.

Yes, this is a practical one, though I don't know any box doing that. In all
the boxes I've been using so far, all the extensions are available. But since 
BIOS vendor may also impact the availability of CPUID bits, I think we 
should do it right by strictly conforming to theSDM. I.e. we need check 
CPUID leafs and then verify all Cx states propagated from dom0, instead
of blindly following its info. Will work a patch for that.

Thanks
Kevin

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel