[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <4A12C84A.5070100@redhat.com>
Date: Tue, 19 May 2009 16:55:06 +0200
From: Gerd Hoffmann <kraxel@...hat.com>
To: Ingo Molnar <mingo@...e.hu>
CC: Jan Beulich <JBeulich@...ell.com>,
Jeremy Fitzhardinge <jeremy@...p.org>,
Xen-devel <xen-devel@...ts.xensource.com>,
the arch/x86 maintainers <x86@...nel.org>,
Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
Jesse Barnes <jbarnes@...tuousgeek.org>,
"Eric W. Biederman" <ebiederm@...ssion.com>,
"H. Peter Anvin" <hpa@...or.com>,
Thomas Gleixner <tglx@...utronix.de>,
Linus Torvalds <torvalds@...ux-foundation.org>
Subject: Re: [Xen-devel] Re: [GIT PULL] xen /proc/mtrr implementation
>>>> No, the linux kernel probably should do the wrmsr on one cpu only then.
>>> Why?
> | The change of MTRR's on _any_ of the guest CPUs in a dom0 context
> | should immediately be refected on all CPUs. Assymetric MTRR
> | settings are madness.
Exactly. And thats why it is pointless to let the dom0 kernel write the
mtrr msrs on more than one cpu.
>>>> Oops, the third "proper technical solutions" is missing.
>>> Yeah, the third one is to not touch MTRRs after bootup and use PAT.
>> Works only in case the CPU has PAT support.
>
> Which specific CPU without PAT support do you worry about?
For example: I have a Notebook here, with MTRR and without PAT
according to the boot log. "Pentium III (Coppermine)" says /proc/cpuinfo.
cheers,
Gerd
--
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