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: "Tian, Kevin" <kevin.tian@xxxxxxxxx>, "xen-devel@xxxxxxxxxxxxxxxxxxx" <xen-devel@xxxxxxxxxxxxxxxxxxx>
Subject: [Xen-devel] Re: expose MWAIT to dom0
From: Keir Fraser <keir.xen@xxxxxxxxx>
Date: Tue, 16 Aug 2011 07:31:13 +0100
Cc: "Zhang, Yang Z" <yang.z.zhang@xxxxxxxxx>, "Wei, Gang" <gang.wei@xxxxxxxxx>, Jan Beulich <JBeulich@xxxxxxxxxx>
Delivery-date: Mon, 15 Aug 2011 23:32:22 -0700
Dkim-signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=user-agent:date:subject:from:to:cc:message-id:thread-topic :thread-index:in-reply-to:mime-version:content-type :content-transfer-encoding; bh=8tYvKKoGCeEL9pn20IgEukZpHhkXiOOd1ArUCzxY/+Y=; b=dUMxnesZ3O1pAGY505RPO9XnMVL3Zv06da9+h0Qr7hYTaiagukjpRYO5VQWWhR2gcC ZzUbjJwzgjLnKGsjXR0SNELMnWWdojsBvsijieb4zkYV11U4yGVsLE2eI3s/02kur7ND 0W+QJBbwYHzTn0W3DyDaKWZUxIDHpB0pKM/Dk=
Envelope-to: www-data@xxxxxxxxxxxxxxxxxxx
In-reply-to: <625BA99ED14B2D499DC4E29D8138F15062DA3898FD@xxxxxxxxxxxxxxxxxxxxxxxxxxxx>
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>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
Thread-index: Acxa+ymibBfDa2PpTRKdAF4mJFeEFAAHRLo3AACWc5AAASamtgAADcSgAADZNOcAAAbekAABySd1ACoXqGAAAusdSA==
Thread-topic: expose MWAIT to dom0
User-agent: Microsoft-Entourage/12.30.0.110427


On 16/08/2011 06:34, "Tian, Kevin" <kevin.tian@xxxxxxxxx> wrote:

>> 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.

It does require xen_cpuidle=0 to be added to the Xen command line. That's
not great.

> 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.

I think (a) is the right way to go.

 -- Keir

> Thanks
> Kevin



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