Could anyone summarize what the support status of cpu frequency changes is at present. I don''t seem to recall generic changes to the hpyervisor in that respect, but the linux tree has fairly extensive changes to the powernow-k8 driver (which would make sense to me only if all other cpufreq drivers are fully supported now, too). Thanks, Jan _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
> Could anyone summarize what the support status of cpu > frequency changes is at present. I don''t seem to > recall generic changes to the hpyervisor in > that respect, but the linux tree has fairly extensive > changes to the powernow-k8 driverKeir rewrote and committed patches from me that: * allow the dom0 kernel to write to the fid/vid k8 pstate control and status MSRs if and only if "cpufreq=dom0-kernel" is passed on the Xen command line * modify time-xen.c to add cpufreq notifier support, and to modify the clock frequency of the hypervisor through a platform hypercall * add platform hypercalls to change the hypervisor clock frequency and to get the idle ticks of all the physical processors * make powernow-k8 use the _PSD structure to determine what cores in the system share frequencies still to be done: * allow the dom0 kernel to write to the architectural pstate control MSR (Opteron 3rd gen and later processors) * modify the cpufreq ondemand governor to use the platform hypercall to get the idle load. I''m working on this now, but Xen and Linux have different ideas of what a "tick" is, so it wasn''t as simple as I''d hoped. * add the patch to have powernow-k8 only use the architectural registers for pstate control for Opteron 3rd gen and later processors * get the _PSD mods accepted into the mainstream kernel; they were submitted but Dave Jones didn''t commit them for some reason.> (which would make sense to me only if all other cpufreq > drivers are fully supported now, too).I don''t understand this; the changes I made in the Linux tree were not prompted by the Xen code. What are you trying to say? -Mark Langsdorf Operating System Research Center AMD _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
>>> "Langsdorf, Mark" <mark.langsdorf@amd.com> 17.10.07 15:56 >>> >> Could anyone summarize what the support status of cpu >> frequency changes is at present. I don''t seem to >> recall generic changes to the hpyervisor in >> that respect, but the linux tree has fairly extensive >> changes to the powernow-k8 driver >... >> (which would make sense to me only if all other cpufreq >> drivers are fully supported now, too). > >I don''t understand this; the changes I made in the >Linux tree were not prompted by the Xen code. What >are you trying to say?The question is whether *any* of the cpufreq drivers will now work (with Xen properly adjusting to the changed frequency) versus whether this now can only be expected to work for powernow-k8 (plus perhaps acpi-cpufreq). In the latter case I''d likely continue to have the CPU_FREQ selector depend on !XEN in our kernels, instead of the more fragile disabling of individual drivers... The cpufreq notifier would suggest it''s generic, but the MSR accesses needed by other drivers would suggest it''s not. Jan _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
On 17/10/07 15:20, "Jan Beulich" <jbeulich@novell.com> wrote:> The question is whether *any* of the cpufreq drivers will now work (with > Xen properly adjusting to the changed frequency) versus whether this > now can only be expected to work for powernow-k8 (plus perhaps > acpi-cpufreq). In the latter case I''d likely continue to have the > CPU_FREQ selector depend on !XEN in our kernels, instead of the > more fragile disabling of individual drivers... > > The cpufreq notifier would suggest it''s generic, but the MSR accesses > needed by other drivers would suggest it''s not.It''s definitely k8-powernow only right now. acpi-cpufreq might work if the control register is an i/o port. It won''t work if the control register is an MSR, since the MSR would not be whitelisted in the WRMSR emulation in emulate_privileged_op(). -- Keir _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
>>> Keir Fraser <Keir.Fraser@cl.cam.ac.uk> 17.10.07 16:34 >>> >On 17/10/07 15:20, "Jan Beulich" <jbeulich@novell.com> wrote: > >> The question is whether *any* of the cpufreq drivers will now work (with >> Xen properly adjusting to the changed frequency) versus whether this >> now can only be expected to work for powernow-k8 (plus perhaps >> acpi-cpufreq). In the latter case I''d likely continue to have the >> CPU_FREQ selector depend on !XEN in our kernels, instead of the >> more fragile disabling of individual drivers... >> >> The cpufreq notifier would suggest it''s generic, but the MSR accesses >> needed by other drivers would suggest it''s not. > >It''s definitely k8-powernow only right now. acpi-cpufreq might work if the >control register is an i/o port. It won''t work if the control register is an >MSR, since the MSR would not be whitelisted in the WRMSR emulation in >emulate_privileged_op().Does ACPI have means to specify MSRs as the access mechanism? I don''t recall platform specific behavior like this, I thought this was restricted to the set of types named ACPI_ADR_SPACE_* in Linux'' include/acpi/actypes.h (and which already goes beyond what is in ACPI 3.0b). Jan _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
On 17/10/07 16:11, "Jan Beulich" <jbeulich@novell.com> wrote:>> It''s definitely k8-powernow only right now. acpi-cpufreq might work if the >> control register is an i/o port. It won''t work if the control register is an >> MSR, since the MSR would not be whitelisted in the WRMSR emulation in >> emulate_privileged_op(). > > Does ACPI have means to specify MSRs as the access mechanism? I don''t > recall platform specific behavior like this, I thought this was restricted to > the set of types named ACPI_ADR_SPACE_* in Linux'' include/acpi/actypes.h > (and which already goes beyond what is in ACPI 3.0b).Well, kind of but not really. ACPI_ADR_SPACE_FIXED_HARDWARE is used, and this is a cop-out in the ACPI spec which means ''the OS needs extra info from the CPU vendor''. So typically for power management it means that CPUID must be mined to discover whether e.g., PowerNow or EnhancedSpeedStep MSRs should be used. This effectively means that the range of possible power-management MSRs is very limited (since they cannot be specified dynamically in the ACPI tables) and Xen itself should easily be able to probe for and dynamically white-list available MSRs as appropriate. Probably all that needs to be added is support for EnhancedSpeedStep MSRs, since we already have PowerNow support. -- Keir _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
>>> Keir Fraser <Keir.Fraser@cl.cam.ac.uk> 17.10.07 17:22 >>> >On 17/10/07 16:11, "Jan Beulich" <jbeulich@novell.com> wrote: > >>> It''s definitely k8-powernow only right now. acpi-cpufreq might work if the >>> control register is an i/o port. It won''t work if the control register is an >>> MSR, since the MSR would not be whitelisted in the WRMSR emulation in >>> emulate_privileged_op(). >> >> Does ACPI have means to specify MSRs as the access mechanism? I don''t >> recall platform specific behavior like this, I thought this was restricted to >> the set of types named ACPI_ADR_SPACE_* in Linux'' include/acpi/actypes.h >> (and which already goes beyond what is in ACPI 3.0b). > >Well, kind of but not really. ACPI_ADR_SPACE_FIXED_HARDWARE is used, and >this is a cop-out in the ACPI spec which means ''the OS needs extra info from >the CPU vendor''. So typically for power management it means that CPUID must >be mined to discover whether e.g., PowerNow or EnhancedSpeedStep MSRs should >be used.Looking into this some more, I find that ACPI_ADR_SPACE_FIXED_HARDWARE is mostly unsupported in Linux except for C-state handling, in which case is resolves to MWAIT.>This effectively means that the range of possible power-management MSRs is >very limited (since they cannot be specified dynamically in the ACPI tables) >and Xen itself should easily be able to probe for and dynamically white-list >available MSRs as appropriate. Probably all that needs to be added is >support for EnhancedSpeedStep MSRs, since we already have PowerNow support.Jan _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
>From: Jan Beulich >Sent: 2007年10月24日 16:28 > >Looking into this some more, I find that >ACPI_ADR_SPACE_FIXED_HARDWARE >is mostly unsupported in Linux except for C-state handling, in which case >is >resolves to MWAIT. >FFH is mapped to msr for P-state handling on Intel processors. You can refer to acpi-cpufreq.c in latest native Linux kernel, where have logic to handle both IO space and FFH space. Since 2.6.2*, acpi-cpufreq.c is the preferred cpufreq driver for intel processors. But if you look at the current 2.6.18-xen, acpi-cpufreq.c can only handle I/O space and instead speedstep-centrino.c manipulates FFH, i.e. MSR directly. But because the _PDC capabilities is set to FFH capable in 2.6.18, speedstep_centrino.c becomes the only drive working in this environment then. Thanks, Kevin _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
Attached patch allows dom0 to touch P-state control MSRs on Intel processors. As Keir said earlier, I/O space style doesn''t need special handle since by default dom0 can access I/O ports unless explicitly denied. A correction to earlier comment. Based on processor stepping, users have to try both acpi_cpufreq (for I/O) and speedstep_centrino (for MSR) drivers to see which one works, when xen-linux still stays at 2.6.18. But once xen-linux syncs to latest kernel version, acpi_cpufreq then becomes the default one for both cases. But at the same time, I would not suggest enabling on-demand governor by default before confirming its correctness. Thanks, Kevin>From: Tian, Kevin >Sent: 2007年10月24日 16:39 > >>From: Jan Beulich >>Sent: 2007年10月24日 16:28 >> >>Looking into this some more, I find that >>ACPI_ADR_SPACE_FIXED_HARDWARE >>is mostly unsupported in Linux except for C-state handling, in which >case >>is >>resolves to MWAIT. >> > >FFH is mapped to msr for P-state handling on Intel processors. You >can refer to acpi-cpufreq.c in latest native Linux kernel, where have >logic to handle both IO space and FFH space. > >Since 2.6.2*, acpi-cpufreq.c is the preferred cpufreq driver for >intel processors. > >But if you look at the current 2.6.18-xen, acpi-cpufreq.c can only handle >I/O space and instead speedstep-centrino.c manipulates FFH, i.e. MSR >directly. But because the _PDC capabilities is set to FFH capable in >2.6.18, speedstep_centrino.c becomes the only drive working in this >environment then. > >Thanks, >Kevin > >_______________________________________________ >Xen-devel mailing list >Xen-devel@lists.xensource.com >http://lists.xensource.com/xen-devel_______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel