From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1LAscw-0002De-UC for qemu-devel@nongnu.org; Thu, 11 Dec 2008 15:59:19 -0500 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1LAscv-0002Bw-2I for qemu-devel@nongnu.org; Thu, 11 Dec 2008 15:59:18 -0500 Received: from [199.232.76.173] (port=40915 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1LAscu-0002Bd-O4 for qemu-devel@nongnu.org; Thu, 11 Dec 2008 15:59:16 -0500 Received: from yx-out-1718.google.com ([74.125.44.154]:51061) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1LAscu-0006YY-6X for qemu-devel@nongnu.org; Thu, 11 Dec 2008 15:59:16 -0500 Received: by yx-out-1718.google.com with SMTP id 3so523604yxi.82 for ; Thu, 11 Dec 2008 12:59:15 -0800 (PST) Message-ID: <49417F1F.6050802@codemonkey.ws> Date: Thu, 11 Dec 2008 14:59:11 -0600 From: Anthony Liguori MIME-Version: 1.0 Subject: Re: [Qemu-devel] [PATCH] MTRR support on x86, part 1 References: <49385D0B.2010703@gmx.net> In-Reply-To: <49385D0B.2010703@gmx.net> Content-Type: text/plain; charset=UTF-8; format=flowed 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 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. > Handle common x86 MTRR reads and writes, but don't act on them. > > One open question remains: Is CPUX86State initialized with zeros or do I > have to zero the MTRR settings stored there explicitly? > > Signed-off-by: Carl-Daniel Hailfinger > > Index: target-i386/cpu.h > =================================================================== > --- target-i386/cpu.h (revision 5879) > +++ target-i386/cpu.h (working copy) > @@ -261,8 +261,25 @@ > > #define MSR_IA32_PERF_STATUS 0x198 > > +#define MSR_MTRRphysBase(reg) (0x200 + 2 * (reg)) > +#define MSR_MTRRphysMask(reg) (0x200 + 2 * (reg) + 1) > + > +#define MSR_MTRRfix64K_00000 0x250 > +#define MSR_MTRRfix16K_80000 0x258 > +#define MSR_MTRRfix16K_A0000 0x259 > +#define MSR_MTRRfix4K_C0000 0x268 > +#define MSR_MTRRfix4K_C8000 0x269 > +#define MSR_MTRRfix4K_D0000 0x26a > +#define MSR_MTRRfix4K_D8000 0x26b > +#define MSR_MTRRfix4K_E0000 0x26c > +#define MSR_MTRRfix4K_E8000 0x26d > +#define MSR_MTRRfix4K_F0000 0x26e > +#define MSR_MTRRfix4K_F8000 0x26f > I'm not a huge fan of the naming convention here. > #define MSR_PAT 0x277 > > +#define MSR_MTRRdefType 0x2ff > + > #define MSR_EFER 0xc0000080 > > #define MSR_EFER_SCE (1 << 0) > @@ -629,6 +646,14 @@ > uint32_t cpuid_ext3_features; > uint32_t cpuid_apic_id; > > + /* MTRRs */ > + uint64_t mtrr_fixed[11]; > + uint64_t mtrr_deftype; > + struct { > + uint64_t base; > + uint64_t mask; > + } mtrr_var[8]; > These have to be saved/restored or else you'll potentially break live migration/savevm/loadvm. Regards, Anthony Liguori