Re: expose MWAIT to dom0

[Keir Fraser <keir.xen@gmail.com>]

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

>> From: Keir Fraser [mailto:keir.xen@gmail.com]
>> Sent: Monday, August 15, 2011 5:02 PM
>> 
>> On 15/08/2011 09:14, "Tian, Kevin" <kevin.tian@intel.com> 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