[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Xen-devel] RE: expose MWAIT to dom0

> From: Keir Fraser [mailto:keir.xen@xxxxxxxxx]
> Sent: Monday, August 15, 2011 3:45 PM
> On 15/08/2011 08:13, "Tian, Kevin" <kevin.tian@xxxxxxxxx> wrote:
> >> Well the problem is some older kernels will try to use MWAIT if they see 
> >> the
> >> feature in CPUID. Of course that doesn't work outside ring 0.
> >>
> >
> > if those old kernels are still of interest, then possibly a boot option in 
> > Xen
> > would
> > be applausive. Or can we just allow selectively exposing MWAIT when xen
> > cpuidle is enabled?
> The kernel could unconditionally advertise MWAIT from its cpuid pv_ops hook?
> If all that's doing is causing relevant parts of BIOS tables to be parsed,
> would that be safe when MWAIT is not in fact available?

It's not safe to unconditionally advertise MWAIT, since if underlying CPU 
support it you'll get invalid op in Xen when attempting to use it. This is why I
want to see MWAIT expose to guest base on real cpu capability, even when I
say selectively expose it under xen cpuidle. :-)

> Else the kernel could get the flag from the real non paravirtualised CPUID
> instruction.

linux uses cpu_has to extract mwait capability. To use real cpuid instruction, 
we need change Linux code which is not worthy though, like below:
       if (!cpu_has(c, X86_FEATURE_MWAIT))
               buf[2] &= ~(ACPI_PDC_C_C2C3_FFH);
If we make it into cpu_has bits, then it lacks of original guarding effect.

So how about the change like below?

-        __clear_bit(X86_FEATURE_MWAIT % 32, &c);
+        if ( !IS_PRIV(current->domain) || !xen_cpuidle )
+            __clear_bit(X86_FEATURE_MWAIT % 32, &c);


Xen-devel mailing list



Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.