Bug 559762 - QEMU driver nodeinfo is wrong when using cpufreq scaling
Summary: QEMU driver nodeinfo is wrong when using cpufreq scaling
Keywords:
Status: CLOSED WONTFIX
Alias: None
Product: Virtualization Tools
Classification: Community
Component: libvirt
Version: unspecified
Hardware: All
OS: Linux
low
medium
Target Milestone: ---
Assignee: Libvirt Maintainers
QA Contact:
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2010-01-28 22:05 UTC by Thomas Treutner
Modified: 2016-03-20 23:37 UTC (History)
4 users (show)

Fixed In Version:
Clone Of:
Environment:
Last Closed: 2016-03-20 23:37:25 UTC
Embargoed:


Attachments (Terms of Use)

Description Thomas Treutner 2010-01-28 22:05:24 UTC
Description of problem:
When using cpufreq kernel module with e.g. ondemand governor, libvirt nodeinfo gets cpu frequency wrong as it just reads /proc/cpuinfo

Version-Release number of selected component (if applicable):
latest git

How reproducible:


Steps to Reproduce:
1. modprobe cpufreq_ondemand
2. virsh -c qemu:///system nodeinfo

  
Actual results:
e.g. 800 MHz, as in /sys/devices/system/cpu/cpuN/cpufreq/cpuinfo_cur_freq

Expected results:
e.g. 3200 MHz, as in /sys/devices/system/cpu/cpuN/cpufreq/scaling_max_freq

Additional info:
I think it would make sense to consider the case where someone might set different max frequencies for different cores. I think i7 supports it? Problem is, data structures would get more complicated, as frequency would have to be stored per core.

/sys/devices/system/cpu/cpuN/cpufreq/cpuinfo_max_freq should IMHO not be considered, as it doesn't consider the current scaling governor.

Comment 1 Cole Robinson 2016-03-20 23:37:25 UTC
Sorry this never received a response. We get the CPU speed from /proc/cpuinfo... it's really just a bit of info about the host and not meant to be an accurate representation of what the host is currently running at. Closing as WONTFIX


Note You need to log in before you can comment on or make changes to this bug.