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 PHC | |
Open Source and information security mailing list archives
| ||
|
Date: Fri, 03 Jan 2014 23:46:35 +0100 From: "Rafael J. Wysocki" <rjw@...ysocki.net> To: Gleb Natapov <gleb@...nel.org> Cc: Dirk Brandewie <dirk.brandewie@...il.com>, Kashyap Chamarthy <kchamart@...hat.com>, Josh Boyer <jwboyer@...oraproject.org>, One Thousand Gnomes <gnomes@...rguk.ukuu.org.uk>, Viresh Kumar <viresh.kumar@...aro.org>, "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 On Friday, January 03, 2014 08:04:36 PM Gleb Natapov wrote: > On Fri, Jan 03, 2014 at 09:30:28AM -0800, Dirk Brandewie wrote: > > Hi All, > > > > Sorry for being late to the party but I just got back from vacation. > > > > There is something deeply wrong here. We should have never gotten to > > intel_pstate_init_cpu(). The VM had to have returned value from the read > > of the max pstate at driver init time and 0 when the CPU was being brought up. > > > > intel_pstate_msrs_not_valid() was added to solve this issue early on > > if I remember correctly it was Josh that reported it then. Is there > > a definative way to detect whether we are running in a VM? > > > Checking for VM is a wrong thing to do here. KVM should behave like it > does not support p-state. > > > Can some one tell me how the nested environment differs in regards to > > reading MSRs? > > > It shouldn't differ, but there may be bug somewhere in nested emulation. > We shouldn't try and hind the bug by doing more checks in Linux but > rather fixing KVM bug that causes Linux to behave incorrectly. Well, fixing the KVM bug is surely welcome. That said, adding checks to ensure that your assumptions are valid is rarely wrong, especially if they are done once per kernel boot. And the kernel only should panic if it cannot continue to run, which isn't the case here. Thanks, Rafael -- 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/
Powered by blists - more mailing lists