[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Qemu-devel] [PATCH] MTRR support on x86, part 1
From: |
Carl-Daniel Hailfinger |
Subject: |
Re: [Qemu-devel] [PATCH] MTRR support on x86, part 1 |
Date: |
Thu, 11 Dec 2008 22:14:41 +0100 |
User-agent: |
Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8.1.17) Gecko/20080922 SUSE/1.1.12-0.1 SeaMonkey/1.1.12 |
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
>> <address@hidden>
>>
>> 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/