qemu-devel.nongnu.org archive mirror
 help / color / mirror / Atom feed
From: Carl-Daniel Hailfinger <c-d.hailfinger.devel.2006@gmx.net>
To: qemu-devel@nongnu.org
Subject: Re: [Qemu-devel] [PATCH] MTRR support on x86, part 1
Date: Thu, 11 Dec 2008 22:14:41 +0100	[thread overview]
Message-ID: <494182C1.8090300@gmx.net> (raw)
In-Reply-To: <49417F1F.6050802@codemonkey.ws>

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
>> <c-d.hailfinger.devel.2006@gmx.net>
>>
>> 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/

  reply	other threads:[~2008-12-11 21:14 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2008-12-04 22:43 [Qemu-devel] [PATCH] MTRR support on x86, part 1 Carl-Daniel Hailfinger
2008-12-11 20:59 ` Anthony Liguori
2008-12-11 21:14   ` Carl-Daniel Hailfinger [this message]
2008-12-11 22:10   ` Carl-Daniel Hailfinger
2008-12-11 22:37     ` Carl-Daniel Hailfinger
2009-01-21 17:00       ` [Qemu-devel] [PATCH] MTRR support on x86 [resend] Carl-Daniel Hailfinger
2009-01-22  3:03         ` Carl-Daniel Hailfinger
2009-01-26 17:53         ` Anthony Liguori

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=494182C1.8090300@gmx.net \
    --to=c-d.hailfinger.devel.2006@gmx.net \
    --cc=qemu-devel@nongnu.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).