Xen devel - Dec 2012 - Using collectd: CPUFreq in dom0

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)