From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1LPprE-00027W-Lx for qemu-devel@nongnu.org; Wed, 21 Jan 2009 22:03:52 -0500 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1LPprD-00027B-1Y for qemu-devel@nongnu.org; Wed, 21 Jan 2009 22:03:52 -0500 Received: from [199.232.76.173] (port=34223 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1LPprC-000272-QK for qemu-devel@nongnu.org; Wed, 21 Jan 2009 22:03:50 -0500 Received: from mail.gmx.net ([213.165.64.20]:44381) by monty-python.gnu.org with smtp (Exim 4.60) (envelope-from ) id 1LPprC-0003YV-4q for qemu-devel@nongnu.org; Wed, 21 Jan 2009 22:03:50 -0500 Message-ID: <4977E217.2030303@gmx.net> Date: Thu, 22 Jan 2009 04:03:51 +0100 From: Carl-Daniel Hailfinger MIME-Version: 1.0 Subject: Re: [Qemu-devel] [PATCH] MTRR support on x86 [resend] References: <49385D0B.2010703@gmx.net> <49417F1F.6050802@codemonkey.ws> <49418FCB.5010607@gmx.net> <49419611.7070203@gmx.net> <497754BD.2000402@gmx.net> In-Reply-To: <497754BD.2000402@gmx.net> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Reply-To: qemu-devel@nongnu.org List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: qemu-devel@nongnu.org Cc: Marcelo Tosatti On 21.01.2009 18:00, Carl-Daniel Hailfinger wrote: > The current codebase ignores MTRR (Memory Type Range Register) > configuration writes and reads because Qemu does not implement caching. > All BIOS/firmware in know of for x86 do implement a mode called > Cache-as-RAM (CAR) which locks down the CPU cache lines and uses the CPU > cache like RAM before RAM is enabled. Qemu assumes RAM is accessible > from the start, but it would be nice to be able to run real > BIOS/firmware in Qemu. For that, we need CAR support and for CAR support > we have to support MTRRs. > > This patch is a first step in that direction. MTRRs are MSRs supported > by all recent x86 CPUs, even old i586. Besides influencing cache, the > MTRRs can be written and read back, so discarding MTRR writes violates > the expectations of existing code out there. > > An added benefit of this patch is that it fixes the following Linux > kernel error message present in recent kernels (provided the BIOS has > the recent MTRR patches applied): > ------------[ cut here ]------------ > WARNING: at arch/x86/kernel/cpu/mtrr/main.c:1500 mtrr_trim_uncached_memory+0x382/0x384() > WARNING: strange, CPU MTRRs all blank? > Modules linked in: > Supported: Yes > Pid: 0, comm: swapper Not tainted 2.6.27.7-9-default #1 > [] dump_trace+0x6b/0x249 > [] show_trace+0x20/0x39 > [] dump_stack+0x71/0x76 > [] warn_slowpath+0x6f/0x90 > [] mtrr_trim_uncached_memory+0x382/0x384 > [] setup_arch+0x40d/0x639 > [] start_kernel+0x6b/0x31f > ======================= > ---[ end trace 4eaa2a86a8e2da22 ]--- > > Handle common x86 MTRR reads and writes, but don't act on them. > > Signed-off-by: Carl-Daniel Hailfinger > Just a short heads-up: Since one of the BIOS MTRR support patches is a bit incomplete, this patch is not enough to silence that Linux warning. I'll post a new patch with improved compatibility tomorrow. Regards, Carl-Daniel -- http://www.hailfinger.org/