WARNING - OLD ARCHIVES

This is an archived copy of the Xen.org mailing list, which we have preserved to ensure that existing links to archives are not broken. The live archive, which contains the latest emails, can be found at http://lists.xen.org/
   
 
 
Xen 
 
Home Products Support Community News
 
   
 

xen-devel

RE: [Xen-devel] expose MWAIT to dom0

To: Jan Beulich <JBeulich@xxxxxxxxxx>
Subject: RE: [Xen-devel] expose MWAIT to dom0
From: "Tian, Kevin" <kevin.tian@xxxxxxxxx>
Date: Tue, 16 Aug 2011 14:53:56 +0800
Accept-language: en-US
Acceptlanguage: en-US
Cc: "Zhang, Yang Z" <yang.z.zhang@xxxxxxxxx>, "xen-devel@xxxxxxxxxxxxxxxxxxx" <xen-devel@xxxxxxxxxxxxxxxxxxx>, Keir Fraser <keir@xxxxxxx>, "Wei, Gang" <gang.wei@xxxxxxxxx>
Delivery-date: Mon, 15 Aug 2011 23:54:48 -0700
Envelope-to: www-data@xxxxxxxxxxxxxxxxxxx
In-reply-to: <4E4A2D5A0200007800051629@xxxxxxxxxxxxxxxxxxxx>
List-help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-id: Xen developer discussion <xen-devel.lists.xensource.com>
List-post: <mailto:xen-devel@lists.xensource.com>
List-subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
List-unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
References: <625BA99ED14B2D499DC4E29D8138F15062D2E80C3A@xxxxxxxxxxxxxxxxxxxxxxxxxxxx> <4E48EEB50200007800051398@xxxxxxxxxxxxxxxxxxxx> <625BA99ED14B2D499DC4E29D8138F15062D2E80DE8@xxxxxxxxxxxxxxxxxxxxxxxxxxxx> <4E49111E0200007800051441@xxxxxxxxxxxxxxxxxxxx> <625BA99ED14B2D499DC4E29D8138F15062DA38993E@xxxxxxxxxxxxxxxxxxxxxxxxxxxx> <4E4A2D5A0200007800051629@xxxxxxxxxxxxxxxxxxxx>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
Thread-index: Acxb34C4ClmyWlCJSyWGT0csuUPBJAAAGF4A
Thread-topic: [Xen-devel] expose MWAIT to dom0
> 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