Re: [Qemu-devel] Modeling x86 early initialization accurately

[Avi Kivity <avi@redhat.com>]

Carl-Daniel Hailfinger wrote:
> Grepping the source code didn't find any code signaling a #GP. I'd be
> thankful for any hints so I can create a patch for this.
>   

See helper_wrmsr(), the default: case (which is even commented).

> (And give a warning to the ReactOS developers because their latest code
> will #GP with that change. They read and write MSR 0x0000008b which is
> unimplemented in QEMU).
>
>   

This may be an architectural msr (oxymoron, yes) which is guaranteed to 
exist.  In that case qemu should implement it.

  

>> If we can detect this, we can handle it with kvm by allocating a
>> memory slot to back the cache.  But I don't see how we can detect it
>> reliably (mtrrs are handled completely within the kernel, and I
>> wouldn't want this hack in the kernel).
>>     
>
> AFAICS MTRRs of x86 targets are ignored completely by QEMU. 

But not kvm.

> They are
> handled as unknown MSR reads/writes and do not fault. See
> target-i386/op_helper.c:helper_rdmsr() and helper_wrmsr(). I'm not
> familiar with how KVM handles the MTRRs and the KVM code in the QEMU
> doesn't provide that many clues. Your statement about MTRR handling in
> the kernel is not entirely clear to me. Are all MSR writes handled in
> the kernel by KVM?
>
> Detection of the CAR mode activation can be performed in two ways,
> depending on how close to hardware we want to get:
> 1. Coreboot specific, triggering on the exact sequence of MSR writes
> performed by coreboot.
>   

Definitely not.

> 2. BIOS/firmware agnostic, triggering anytime the cache control bits and
> any of the MTRR MSRs are in the right state.
>   

What is the right state?  Total writeback memory spanned by MTRRs <= 
cache size?

-- 
error compiling committee.c: too many arguments to function