Hello, I''ve tried to get the CPUFreq plugin of collectd running in dom0. But I mentioned that it isn''t so easy to get a file in sysfs on the rigth place. I know that the value has to come from hypervisor and I''ve seen the code in xenpm. The only value I need is "/sys/devices/system/cpu/cpu0/cpufreq/scaling_cur_freq" which would create cpufreq.c. Can anyone help me by giving me some hints? I''ve read many websites and papers and coded many things. I''m glade to get the sysfs file. With "sysfs_create..." I''ve many trouble but "kobject_add" works fine. Regards, Stefan Kuhne _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
On Tue, Dec 25, 2012 at 07:55:37PM +0100, Stefan Kuhne wrote:> Hello, > > I''ve tried to get the CPUFreq plugin of collectd running in dom0. > But I mentioned that it isn''t so easy to get a file in sysfs on the > rigth place. > > I know that the value has to come from hypervisor and I''ve seen the code > in xenpm.Right. Did you look in the source code from xenpm?> > The only value I need is > "/sys/devices/system/cpu/cpu0/cpufreq/scaling_cur_freq" which would > create cpufreq.c. > > Can anyone help me by giving me some hints? > I''ve read many websites and papers and coded many things. > I''m glade to get the sysfs file. > > With "sysfs_create..." I''ve many trouble but "kobject_add" works fine. > > Regards, > Stefan Kuhne >> _______________________________________________ > Xen-devel mailing list > Xen-devel@lists.xen.org > http://lists.xen.org/xen-devel
Am 04.01.2013 22:11, schrieb Konrad Rzeszutek Wilk:> On Tue, Dec 25, 2012 at 07:55:37PM +0100, Stefan Kuhne wrote:Hello Konrad, a happy new year and thanks for your reply.>> I know that the value has to come from hypervisor and I''ve seen the code >> in xenpm. > > Right. Did you look in the source code from xenpm?I''ve took a look into it. So I''ve found how xenpm get the values. Is there code with sysfs? My problem is how I can create the required files in sysfs. Original they are created in cpufreq.c. Regards, Stefan Kuhne _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
>>> "Stefan Kuhne" <stefan.kuhne@gmx.net> 01/04/13 10:31 PM >>> >Am 04.01.2013 22:11, schrieb Konrad Rzeszutek Wilk: > On Tue, Dec 25, 2012 at 07:55:37PM +0100, Stefan Kuhne wrote: >>> I know that the value has to come from hypervisor and I''ve seen the code >>> in xenpm. >> >> Right. Did you look in the source code from xenpm? > >I''ve took a look into it. >So I''ve found how xenpm get the values. >Is there code with sysfs? > >My problem is how I can create the required files in sysfs. >Original they are created in cpufreq.c.Are you aware that this cannot be done in a way directly fitting the native case, since Dom0''s vCPU-s don''t match the system''s pCPU-s, and hence you''d need a separate representation, along with (where necessary, e.g. when wanting to access MSRs like MPERF/APERF) fiddling with vCPU affinities for obtaining/consuming the data? Jan
On Fri, Jan 04, 2013 at 10:29:25PM +0100, Stefan Kuhne wrote:> Am 04.01.2013 22:11, schrieb Konrad Rzeszutek Wilk: > > On Tue, Dec 25, 2012 at 07:55:37PM +0100, Stefan Kuhne wrote: > > Hello Konrad, > > a happy new year and thanks for your reply.Happy New Year as well!> > >> I know that the value has to come from hypervisor and I''ve seen the code > >> in xenpm. > > > > Right. Did you look in the source code from xenpm? > > I''ve took a look into it. > So I''ve found how xenpm get the values.Right, so it does some hypercalls to fetch that data.> Is there code with sysfs?I wrote some experimental that some time ago: http://git.kernel.org/?p=linux/kernel/git/konrad/xen.git;a=shortlog;h=refs/heads/stable/cpufreq-xen.v6 but looking at it I am not even sure how it would properly write the MHz values in SysFS. It just latches it to the perf and that is it.> > My problem is how I can create the required files in sysfs. > Original they are created in cpufreq.c.You are running in two problems: 1). The cpufreq API is disabled when it boots under Xen. I did that so that the kernel wouldn''t try to dispatch certain WRMSR which would be ignored by the hypervisor. This git commit 5e6262542 has a nice description of why it was neccessary. You could "re-enable" the cpufreq (revert git commit 48cdd8287) and 2). Have a new "xen" cpufreq driver. It would have to register itself for the cpufreq_register_governor and populate the policy->cpuinfo.min_freq/max_freq, min/max with the information that ''xenpm'' would have gotten. In other words - you would need to shuffle parts of ''xenpm'' source code in a new cpufreq governor driver. That by itself is not that hard (you could even create a thread that would do the hypercalls so often and just populate some internal structure with the new values). The problem is the hypercall. It is version gated on the do_sysctl: 42 if ( op->interface_version != XEN_SYSCTL_INTERFACE_VERSION ) 43 return -EACCES; 44 which for Xen 4.3 is 37 #define XEN_SYSCTL_INTERFACE_VERSION 0x00000009 but for Xen 4.1 is: #define XEN_SYSCTL_INTERFACE_VERSION 0x00000008 So you would have to figure out what the version is to work with different versions of hypervisor.> > > Regards,Hope this helps. It might be just easier to expand the ''xenpm'' code to be invoked from your collect scripts?> Stefan Kuhne >
Monday, January 7, 2013, 4:53:17 PM, you wrote:> On Fri, Jan 04, 2013 at 10:29:25PM +0100, Stefan Kuhne wrote: >> Am 04.01.2013 22:11, schrieb Konrad Rzeszutek Wilk: >> > On Tue, Dec 25, 2012 at 07:55:37PM +0100, Stefan Kuhne wrote: >> >> Hello Konrad, >> >> a happy new year and thanks for your reply.> Happy New Year as well! >> >> >> I know that the value has to come from hypervisor and I''ve seen the code >> >> in xenpm. >> > >> > Right. Did you look in the source code from xenpm? >> >> I''ve took a look into it. >> So I''ve found how xenpm get the values.> Right, so it does some hypercalls to fetch that data. >> Is there code with sysfs?> I wrote some experimental that some time ago:> http://git.kernel.org/?p=linux/kernel/git/konrad/xen.git;a=shortlog;h=refs/heads/stable/cpufreq-xen.v6> but looking at it I am not even sure how it would properly > write the MHz values in SysFS. It just latches it to the perf > and that is it.>> >> My problem is how I can create the required files in sysfs. >> Original they are created in cpufreq.c.> You are running in two problems: > 1). The cpufreq API is disabled when it boots under Xen. I did that > so that the kernel wouldn''t try to dispatch certain WRMSR which > would be ignored by the hypervisor. This git commit 5e6262542 > has a nice description of why it was neccessary.> You could "re-enable" the cpufreq (revert git commit 48cdd8287) and> 2). Have a new "xen" cpufreq driver. It would have to register > itself for the cpufreq_register_governor and populate the > policy->cpuinfo.min_freq/max_freq, min/max with the information > that ''xenpm'' would have gotten. In other words - you would need > to shuffle parts of ''xenpm'' source code in a new cpufreq > governor driver. That by itself is not that hard (you could > even create a thread that would do the hypercalls so often > and just populate some internal structure with the new > values).> The problem is the hypercall. It is version gated on the > do_sysctl:> 42 if ( op->interface_version != XEN_SYSCTL_INTERFACE_VERSION ) > 43 return -EACCES; > 44> which for Xen 4.3 is > 37 #define XEN_SYSCTL_INTERFACE_VERSION 0x00000009 > but for Xen 4.1 is: > #define XEN_SYSCTL_INTERFACE_VERSION 0x00000008> So you would have to figure out what the version is to work with > different versions of hypervisor.>> >> >> Regards,> Hope this helps.> It might be just easier to expand the ''xenpm'' code to be invoked from > your collect scripts?Would be nice to make xenpm have a better "machine readable" output, the current "human readable" output is a bit hard to parse by scripts.>> Stefan Kuhne >>
> > Hope this helps. > > > It might be just easier to expand the ''xenpm'' code to be invoked from > > your collect scripts? > > Would be nice to make xenpm have a better "machine readable" output, the current "human readable" output is a bit hard to parse by scripts.That could also be done. I have no idea what a machine readable output would be for this. Is this something you are volunteering to do :-)? We could always use more patches.
Monday, January 7, 2013, 8:13:23 PM, you wrote:>> > Hope this helps. >> >> > It might be just easier to expand the ''xenpm'' code to be invoked from >> > your collect scripts? >> >> Would be nice to make xenpm have a better "machine readable" output, the current "human readable" output is a bit hard to parse by scripts.> That could also be done. I have no idea what a machine readable output would be > for this. Is this something you are volunteering to do :-)? We could always use > more patches.I will see what i can do :-) .. but it''s queued after getting vga passthrough of my ati card working to a HVM linux guest. (win7 is working)
Apparently Analagous Threads
- [PATCH 1/2] cpufreq, powernow: enable/disable core performance boost for all cpus in policy
- [PATCH V2 1/2] cpufreq, xenpm: fix cpufreq and xenpm mismatch
- xen acpi cpufreq driver
- Unble to find cpufreq driver
- Is: drivers/cpufreq/cpufreq-xen.c Was:Re: [PATCH 2 of 2] linux-xencommons: Load processor-passthru