From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1LAsrw-00048E-LC for qemu-devel@nongnu.org; Thu, 11 Dec 2008 16:14:48 -0500 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1LAsrt-00043F-FO for qemu-devel@nongnu.org; Thu, 11 Dec 2008 16:14:47 -0500 Received: from [199.232.76.173] (port=55246 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1LAsrt-00042m-3x for qemu-devel@nongnu.org; Thu, 11 Dec 2008 16:14:45 -0500 Received: from mail.gmx.net ([213.165.64.20]:45514) by monty-python.gnu.org with smtp (Exim 4.60) (envelope-from ) id 1LAsrs-0000Fx-Cb for qemu-devel@nongnu.org; Thu, 11 Dec 2008 16:14:44 -0500 Message-ID: <494182C1.8090300@gmx.net> Date: Thu, 11 Dec 2008 22:14:41 +0100 From: Carl-Daniel Hailfinger MIME-Version: 1.0 Subject: Re: [Qemu-devel] [PATCH] MTRR support on x86, part 1 References: <49385D0B.2010703@gmx.net> <49417F1F.6050802@codemonkey.ws> In-Reply-To: <49417F1F.6050802@codemonkey.ws> 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 On 11.12.2008 21:59, Anthony Liguori wrote: > 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. Except the MSR_ prefix, this is the name the MTRRs have in the AMD data sheets. I'm open to alternatives, though. If you have a suggestion, I'll implement it. >> #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. Thanks, I was unaware of that. I'll read up on savevm/loadvm and post a new patch. Thanks for the review! Regards, Carl-Daniel -- http://www.hailfinger.org/