linux-kernel - Re: intel_pstate divide error with v3.13-rc4-256-gb7000ad

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Fri, 27 Dec 2013 15:15:39 +0100
From:	Kashyap Chamarthy <kchamart@...hat.com>
To:	Josh Boyer <jwboyer@...oraproject.org>
CC:	Gleb Natapov <gleb@...nel.org>,
	One Thousand Gnomes <gnomes@...rguk.ukuu.org.uk>,
	Viresh Kumar <viresh.kumar@...aro.org>,
	Dirk Brandewie <dirk.brandewie@...il.com>,
	"Rafael J. Wysocki" <rjw@...ysocki.net>,
	"cpufreq@...r.kernel.org" <cpufreq@...r.kernel.org>,
	Linux PM list <linux-pm@...r.kernel.org>,
	"Linux-Kernel@...r. Kernel. Org" <linux-kernel@...r.kernel.org>,
	"Richard W.M. Jones" <rjones@...hat.com>
Subject: Re: intel_pstate divide error with v3.13-rc4-256-gb7000ad

[. . .]

>> KVM does not emulate P-states at all. intel_pstate_init() calls
>> intel_pstate_msrs_not_valid() before printing "Intel P-state driver
>> initializing."  which suppose to fail since it checks that two reads of
>> MSR_IA32_APERF return different values, but KVM does not emulate this msr
>> at all, so both calls should return zero (KVM suppose to inject #GP, all rdmsrl
>> are patched to be rdmsrl_safe in a guest).
>>
>> Anything interesting in host dmesg?

Heya Gleb,

Here's the relevant dmesg snippet (full dmesg, refer the attachment below):
=====
.
.
.
[    3.462741] Intel pstate controlling: cpu 0
[    3.463972] cpufreq: __cpufreq_add_dev: ->get() failed
[    3.465399] Intel pstate controlling: cpu 1
[    3.466505] cpufreq: __cpufreq_add_dev: ->get() failed
[    3.468056] Intel pstate controlling: cpu 2
[    3.469208] cpufreq: __cpufreq_add_dev: ->get() failed
[    3.470751] Intel pstate controlling: cpu 3
[    3.471870] cpufreq: __cpufreq_add_dev: ->get() failed
[    3.473289] Intel pstate controlling: cpu 4
[    3.474545] cpufreq: __cpufreq_add_dev: ->get() failed
[    3.475957] Intel pstate controlling: cpu 5
[    3.477135] cpufreq: __cpufreq_add_dev: ->get() failed
[    3.478544] Intel pstate controlling: cpu 6
[    3.479670] cpufreq: __cpufreq_add_dev: ->get() failed
[    3.481124] Intel pstate controlling: cpu 7
[    3.482288] cpufreq: __cpufreq_add_dev: ->get() failed
[    3.483752] Intel pstate controlling: cpu 8
[    3.484986] cpufreq: __cpufreq_add_dev: ->get() failed
[    3.486396] Intel pstate controlling: cpu 9
[    3.488000] cpufreq: __cpufreq_add_dev: ->get() failed
[    3.489684] Intel pstate controlling: cpu 10
[    3.491027] cpufreq: __cpufreq_add_dev: ->get() failed
[    3.492647] Intel pstate controlling: cpu 11
[    3.494026] cpufreq: __cpufreq_add_dev: ->get() failed
[    3.495662] Intel pstate controlling: cpu 12
[    3.497065] cpufreq: __cpufreq_add_dev: ->get() failed
[    3.498733] Intel pstate controlling: cpu 13
[    3.500071] cpufreq: __cpufreq_add_dev: ->get() failed
[    3.501787] Intel pstate controlling: cpu 14
[    3.503105] cpufreq: __cpufreq_add_dev: ->get() failed
[    3.504809] Intel pstate controlling: cpu 15
[    3.506142] cpufreq: __cpufreq_add_dev: ->get() failed
[    3.507825] Intel pstate controlling: cpu 16
[    3.509175] cpufreq: __cpufreq_add_dev: ->get() failed
[    3.510780] Intel pstate controlling: cpu 17
[    3.512158] cpufreq: __cpufreq_add_dev: ->get() failed
[    3.513765] Intel pstate controlling: cpu 18
[    3.515225] cpufreq: __cpufreq_add_dev: ->get() failed
[    3.516898] Intel pstate controlling: cpu 19
.
.
.
=====

Full dmesg output: https://bugzilla.kernel.org/attachment.cgi?id=119701

  (Kernel bug: https://bugzilla.kernel.org/show_bug.cgi?id=67761)

>> Is it reproducible?

Yes, just now I was able to reproduce it again. It's trivial with
libguestfs-test-tool:

  $ export LIBGUESTFS_BACKEND=direct

  $ guestfish get-backend
  direct

  $ libguestfs-test-tool

You see the Kernel panic on stdout.

NOTE: You can reproduce the issue without setting LIBGUESTFS_BACKEND=direct,
      in which case, it'll default to 'libvirt' back-end.


Version:

  $ uname -r; rpm -q libguestfs libvirt qemu-system-x86
  3.13.0-0.rc4.git5.1.fc21.x86_64
  libguestfs-1.25.18-1.fc21.x86_64
  libvirt-1.1.3.1-2.fc20.x86_64
  qemu-system-x86-1.6.1-2.fc20.x86_64


> 
> Seems reproducible.  I forgot to link to the actual bug in my original
> report, but you can find it here:
> 
> https://bugzilla.redhat.com/show_bug.cgi?id=1046317
> 
> Adding Richard and Kashyap on CC.
> 
> josh
> 


-- 
/kashyap
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/