From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:44567) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1VLXgp-0007NA-8u for qemu-devel@nongnu.org; Mon, 16 Sep 2013 08:14:09 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1VLXgj-0007ew-36 for qemu-devel@nongnu.org; Mon, 16 Sep 2013 08:14:03 -0400 Received: from nodalink.pck.nerim.net ([62.212.105.220]:35880 helo=paradis.irqsave.net) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1VLXgi-0007eZ-Qf for qemu-devel@nongnu.org; Mon, 16 Sep 2013 08:13:57 -0400 Date: Mon, 16 Sep 2013 14:15:46 +0200 From: =?iso-8859-1?Q?Beno=EEt?= Canet Message-ID: <20130916121545.GH5105@irqsave.net> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Subject: [Qemu-devel] cpufreq and QEMU guests List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: cpufreq@vger.kernel.org, qemu-devel@nongnu.org Cc: peter.maydell@linaro.org, gleb@redhat.com, viresh.kumar@linaro.org, agraf@suse.de, rjw@sisk.pl, pbonzini@redhat.com Hello, I know a cloud provider worried about the fact that the /proc/cpuinfo of = his guests give a bogus frequency to his customer. QEMU and the guests kernel currently have no way to reflect the host freq= uency changes to the guests. The customer compute intensive application then read this information and= take wrong decisions. I looked at the various Linux cpufreq drivers and they all seems to be ta= ble based. Is it true ? For example the acpi cpufreq driver have 16 differents pstates at hand to= lookup in the pstate table and get the frequency. Given that guests can migrate from one hardware to a slightly different h= ardware the table may become wrong after live migration. What would be the best hardware to emulate in order to pass an arbitrary frequency to the guest ? Would a pvfreq paravirtualized QEMU hardware and a guest driver implement= ing only the callbacks needed to read the frequency be a good idea ? Best regards Beno=EEt ps: I CC this mail to the other QEMU arch maintainers because the problem mus= t be the same everywhere where KVM run.