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

[Xen-devel] RE: expose MWAIT to dom0

To: Keir Fraser <keir.xen@xxxxxxxxx>, "xen-devel@xxxxxxxxxxxxxxxxxxx" <xen-devel@xxxxxxxxxxxxxxxxxxx>
Subject: [Xen-devel] RE: expose MWAIT to dom0
From: "Tian, Kevin" <kevin.tian@xxxxxxxxx>
Date: Tue, 16 Aug 2011 13:34:50 +0800
Accept-language: en-US
Acceptlanguage: en-US
Cc: "Zhang, Yang Z" <yang.z.zhang@xxxxxxxxx>, "Wei, Gang" <gang.wei@xxxxxxxxx>, Jan Beulich <JBeulich@xxxxxxxxxx>
Delivery-date: Mon, 15 Aug 2011 22:35:36 -0700
Envelope-to: www-data@xxxxxxxxxxxxxxxxxxx
In-reply-to: <CA6E9F31.1F35D%keir.xen@xxxxxxxxx>
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: <625BA99ED14B2D499DC4E29D8138F15062D2E80DF9@xxxxxxxxxxxxxxxxxxxxxxxxxxxx> <CA6E9F31.1F35D%keir.xen@xxxxxxxxx>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
Thread-index: Acxa+ymibBfDa2PpTRKdAF4mJFeEFAAHRLo3AACWc5AAASamtgAADcSgAADZNOcAAAbekAABySd1ACoXqGA=
Thread-topic: expose MWAIT to dom0
> From: Keir Fraser [mailto:keir.xen@xxxxxxxxx]
> Sent: Monday, August 15, 2011 5:02 PM
> 
> On 15/08/2011 09:14, "Tian, Kevin" <kevin.tian@xxxxxxxxx> wrote:
> 
> >> cpu_has() accesses a pre-filled capabilities bitmask, filled from cpuid,
> >> right? And cpuid goes through a pv_ops hook?
> >>
> >
> > I'm not quite catching you here. Do you want to prefill mwait bit from 
> > pv_ops
> > hook unconditionally even in current situation where Xen doesn't expose
> > mwait, or selectively under some dom0's boot option even when Xen is
> > changed to expose mwait? The first case is not sane, while for the 2nd case
> > I don't think any pv_ops hook is required as long as Xen can expose it, 
> > isn't
> > it?
> 
> But there is a pv_ops hook, and Xen isn't going to expose it because it
> breaks old dom0 kernels.
> 

yes, now I understand your suggestion. Basically we discussed two approaches:

a) in current pv_ops hook (xen_cpuid):
        - use unconditional cpuid to query mwait capability on physical cpu
        - if the bit is set, and SIF_PM_MASK indicates xen pm is enabled:
                then set the bit in the ECX when leaf 1 is queried
  this should effectively has X86_FEATURE_MWAIT set, and then _PDC method
will notify BIOS using mwait entry method. 
  This method doesn't require Xen change, but it would only work for future
releases which incorporates this change

b) in Xen we selectively clear MWAIT capability in pv_cpuid, based on whether
xen_cpuidle is enabled. If there's no MWAIT available on physical CPU, or
xen_cpuidle is disabled, MWAIT is not exposed to the guest. This approach
doesn't break old dom0 kernel, as it's controlled by xen_cpuidle cmdline option.
Basically it's not suggested to activate Cx transition by using legacy I/O 
method,
so it's fine to disable xen cpuidle on those old dom0 kernel.

approach a) is better from the angle that we don't want non-ring0 code to
execute MWAIT which causes invalid opcode exception, while for PM purpose
MWAIT is purely informational. 

Approach b) is better if we want existing Xen deployments to use efficient 
C-state benefit, since Xen is backward compatible and thus upgrade to a 
newer Xen release is lighter than upgrading to a newer dom0 kernel.

What's your opinion about this? If b) is not a valid concern from your side, we
will go to a) as you suggested.

Thanks
Kevin

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