Re: [Qemu-devel] [PATCH] MTRR support on x86, part 1

[Carl-Daniel Hailfinger]

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/