Re: [Xen-devel] [PATCH 0/9] Porting the intel_pstate driver to Xen

["Jan Beulich" <jbeulich@xxxxxxxx>]

>>> "Wang, Wei W" <wei.w.wang@xxxxxxxxx> 04/28/15 4:38 PM >>>
>On 28/04/2015 21:29, Jan Beulich wrote
>>>>> "Wang, Wei W" <wei.w.wang@xxxxxxxxx> 04/28/15 3:24 PM >>>
>> >On 28/04/2015 21:14, Jan Beulich wrote
>> >>  >On 25/04/2015 00:15, Konrad Rzeszutek Wilk wrote
>> >> >> How will this affect AMD processors which can use the cpufreq?
>> >> >> Would the ondemand feature go away?
>> >> >
>> >> >No, this won't affect them. When the "intel_pstate=disable" is added
>> >> >to the  booting parameter list, the old cpufreq driver will be used,
>> >> >and everything,  including xenpm, will work in the old style.
>> >>
>> >> That wouldn't suffice. On AMD (and older Intel) platforms it
>> >> shouldn't be necessary to specifiy the option to retain current
>> functionality.
>> >
>> >No problem, I will change it with "intel_pstate=enable" to enable the
>> >intel_pstate driver. Then others will not be bothered.
>> 
>> For new code this might be a good idea anyway, but that wasn't my point.
>> Instead, even with "intel_pstate=enable" on an old Intel (or AMD) system
>> (regardless of doing so being pointless) there shouldn't be any behavioral
>> difference.
>
>Without " intel_pstate=enable" added, the old acpi-cpufreq driver will be 
>loaded, so shouldn't be a problem.

While I would have thought this to be an obvious thing anyway, it looks like
we still don't understand each other. As much as it is (supposed to be)
natural that in the absence of that command line option things behave as
before, it should also be so if the option _was_ given but the driver didn't 
find
suitable hardware.

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel