RE: [Xen-devel] RE: expose MWAIT to dom0

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

> From: Jan Beulich [mailto:JBeulich@xxxxxxxxxx]
> Sent: Monday, August 15, 2011 4:12 PM
> 
> >>> On 15.08.11 at 09:57, "Tian, Kevin" <kevin.tian@xxxxxxxxx> wrote:
> > So how about the change like below?
> >
> > emulate_forced_invalid_op:
> > -        __clear_bit(X86_FEATURE_MWAIT % 32, &c);
> > +        if ( !IS_PRIV(current->domain) || !xen_cpuidle )
> > +            __clear_bit(X86_FEATURE_MWAIT % 32, &c);
> 
> You'd break any Dom0 kernel that uses the flag to determine whether it
> can actually use the mwait/monitor instructions. I agree with Keir that

For those old kernels, then disable cpuidle to revert the effect.

> for this particular purpose the code ought to look at the real CPUID
> flag.
> 
> It should be possible to do this without changing non-Xen code, since
> the use of the instructions is additionally gated on CPUID leaf 5
> producing non-zero output. But again, the kernel has to do this for
> itself, the hypervisor shouldn't expose the feature flag.
> 

Even by using real CPUID, the point is that we either need make it into
cpu capability bits to avoid further change arch_acpi_set_pdc_bits, or
provide Xen's own arch_acpi_set_pdc_bits by looking at real CPUID
result directly. The former has same effect as having Xen expose mwait,
while the latter simply adds more changes to Linux code.

Somehow imho it's easier to switch to a newer Xen release than switching
to a newer dom0 kernel. The latter requires more validations. If we can
make changes in Xen, it's easier for existing deployment to workaround
this issue. Or else only next releases from various OSVs may have the
fix which has long days to go...

Thanks
Kevin

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