[Xen-devel] RE: expose MWAIT to dom0

["Jan Beulich" <JBeulich@xxxxxxxxxx>]

>>> On 15.08.11 at 10:14, "Tian, Kevin" <kevin.tian@xxxxxxxxx> wrote:
>>  From: Keir Fraser [mailto:keir.xen@xxxxxxxxx] 
>> Sent: Monday, August 15, 2011 4:11 PM
>> 
>> On 15/08/2011 08:57, "Tian, Kevin" <kevin.tian@xxxxxxxxx> wrote:
>> 
>> >> 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,
>> > then
>> > 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.
>> 
>> 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?

Didn't you want to make Xen's exposing of the pv bit conditional upon
xen_cpuidle? Dom0 can indirectly see this variable already through
XEN_PROCESSOR_PM_CX being set in SIF_PM_MASK, so it could use it for
its own decision. Whether that's really safe is another matter, as
xen_cpuidle set doesn't mean mwait is actually being used.

Jan


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