[Xen-devel] RE: expose MWAIT to dom0

["Tian, Kevin" <kevin.tian@xxxxxxxxx>]

> 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