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

[Xen-devel] RE: expose MWAIT to dom0

>>> 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.


Xen-devel mailing list



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