RE: [Xen-devel] expose MWAIT to dom0

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

> From: Jan Beulich [mailto:JBeulich@xxxxxxxxxx]
> Sent: Tuesday, August 16, 2011 2:42 PM
> 
> >>> On 16.08.11 at 08:03, "Tian, Kevin" <kevin.tian@xxxxxxxxx> wrote:
> >>  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
> 
> Not following you here: If I execute a "real" cpuid instruction, I will know
> whether mwait is "present".

Sorry. I thought you want to integrate current patch in 2.6.32 pvops tree:
diff --git a/arch/x86/kernel/acpi/processor.c b/arch/x86/kernel/acpi/processor.c
index 8c9526d..d88866c 100644
--- 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, 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] &= ~(ACPI_PDC_C_C2C3_FFH);
 
        obj->type = ACPI_TYPE_BUFFER;

that's definitely wrong.

> 
> > 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.
> 
> You're getting it sort of wrong way round: What I don't want to do (but
> seemingly being necessary) is mimic the decision logic the hypervisor
> uses (i.e. require the break-on-interrupt extension for C2/C3 entering
> through MWAIT) in Dom0 when deciding about the bits to pass to

break-on-interrupt is not a hard requirement to use MWAIT. Even when
that extension is not available, MWAIT can be still used to enter C2/C3,
just with interrupt enabled.

> _PDC. That ought to be an implementation detail (subject to change)
> in the hypervisor alone. The hypervisor itself, otoh, already properly
> checks CPUID leaf 5 (and that's what might cause it to not use mwait
> despite the bit in CPUID leaf 1 being set, which should be all Dom0
> ought to look at for deciding whether to clear ACPI_PDC_C_C2C3_FFH).
> 

I made a mistake, that currently CPUID leaf 5 is already checked in
check_cx in hypervisor, so it should be sane. However I still fail to catch
your real concern here. :/

Thanks,
Kevin

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