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:03:01 +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:05:27 -0700
Envelope-to: www-data@xxxxxxxxxxxxxxxxxxx
In-reply-to: <4E49111E0200007800051441@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>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
Thread-index: AcxbNjYaj2W8yUwbSgeeemLTMxUr8gAoBDZA
Thread-topic: [Xen-devel] expose MWAIT to dom0
> 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