From: Ingo Molnar <mingo@elte.hu>
To: Arjan van de Ven <arjan@linux.intel.com>
Cc: Yinghai Lu <yinghai@kernel.org>,
Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
Linus Torvalds <torvalds@linux-foundation.org>,
NetDev <netdev@vger.kernel.org>,
x86@kernel.org, Andrew Morton <akpm@linux-foundation.org>,
Theodore Ts'o <tytso@mit.edu>,
Alan Cox <alan@lxorguk.ukuu.org.uk>,
jesse Barnes <jbarnes@virtuousgeek.org>,
"H. Peter Anvin" <hpa@zytor.com>
Subject: Re: oops/warning report for the week of November 26, 2008
Date: Fri, 28 Nov 2008 09:34:15 +0100 [thread overview]
Message-ID: <20081128083415.GA1131@elte.hu> (raw)
In-Reply-To: <20081127125301.3cb1e282@linux.intel.com>
* Arjan van de Ven <arjan@linux.intel.com> wrote:
> On Thu, 27 Nov 2008 21:47:14 +0100
> Ingo Molnar <mingo@elte.hu> wrote:
>
> > IIRC the problem is that vmware _does_ claim that it supports MTRRs.
>
> it might.
> but even if they would fix that, we would still WARN (
> at least we should do our side correctly...
As pointed out in other parts of the thread, that is not the case.
Anyway, as i said it in the onset, if you think we should remove the
warning altogether, or tweak it, we can do that - it is important to
have relevant warnings show up in kerneloops.org.
To sum it up: the only remaining MTRR warnings we know of are either:
1) apparently genuine BIOS bugs that do cause problems if the (new)
kernel does not fix them up.
The MTRR warning is relevant and correct in those cases.
or:
2) sucky virtualization solutions that cheat the guest OS by faking
"MTRR support" in the CPUID info, but not actually showing any
MTRRs. These virtualization solutions do not even properly
identify themselves to the kernel.
The MTRR warning is unnecessary in this case.
So what we did in the x86 tree was remove the warning in the second
case - is to properly identify vmware (and in general, virtualization)
guests.
It was not a simple oneliner:
earth4:~/tip> gll linus..x86/detect-hyper
4e42ebd: x86: hypervisor - fix sparse warnings
c450d78: x86: vmware - fix sparse warnings
fd8cd7e: x86: vmware: look for DMI string in the product serial key
6bdbfe9: x86: VMware: Fix vmware_get_tsc code
395628e: x86: Skip verification by the watchdog for TSC clocksource.
eca0cd0: x86: Add a synthetic TSC_RELIABLE feature bit.
88b094f: x86: Hypervisor detection and get tsc_freq from hypervisor
49ab56a: x86: add X86_FEATURE_HYPERVISOR feature bit
b2bcc7b: x86: add a synthetic TSC_RELIABLE feature bit
and it will benefit vmware guests in many more areas than just a
sharper MTRR warning message. That code is queued up for v2.6.29.
Ingo
next prev parent reply other threads:[~2008-11-28 8:34 UTC|newest]
Thread overview: 25+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-11-26 23:11 oops/warning report for the week of November 26, 2008 Arjan van de Ven
2008-11-27 0:05 ` Jesse Barnes
2008-11-27 11:48 ` Ingo Molnar
2008-11-27 19:42 ` Alex Chiang
2008-11-27 19:49 ` Arjan van de Ven
2008-11-27 11:52 ` Ingo Molnar
2008-11-27 17:02 ` Jesse Barnes
2008-11-27 18:01 ` Arjan van de Ven
2008-11-27 20:18 ` Ingo Molnar
2008-11-27 20:28 ` Arjan van de Ven
2008-11-27 20:47 ` Ingo Molnar
2008-11-27 20:53 ` Arjan van de Ven
2008-11-28 8:34 ` Ingo Molnar [this message]
2008-11-27 21:18 ` H. Peter Anvin
2008-11-27 21:18 ` Yinghai Lu
2008-11-27 21:42 ` H. Peter Anvin
2008-11-28 17:18 ` Jay Cliburn
2008-11-28 17:32 ` Arjan van de Ven
2008-11-28 18:36 ` Jay Cliburn
2008-11-28 18:50 ` Arjan van de Ven
2008-11-28 21:12 ` atl1 transmit timeout Was: " Jay Cliburn
2008-11-28 21:22 ` Arjan van de Ven
2008-11-28 19:50 ` Francois Romieu
2008-11-28 20:12 ` Arjan van de Ven
2008-11-30 8:58 ` Roger Luethi
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20081128083415.GA1131@elte.hu \
--to=mingo@elte.hu \
--cc=akpm@linux-foundation.org \
--cc=alan@lxorguk.ukuu.org.uk \
--cc=arjan@linux.intel.com \
--cc=hpa@zytor.com \
--cc=jbarnes@virtuousgeek.org \
--cc=linux-kernel@vger.kernel.org \
--cc=netdev@vger.kernel.org \
--cc=torvalds@linux-foundation.org \
--cc=tytso@mit.edu \
--cc=x86@kernel.org \
--cc=yinghai@kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).