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

[Carl-Daniel Hailfinger <c-d.hailfinger.devel.2006@gmx.net>]

On 27.11.2008 14:28, Avi Kivity wrote:
> 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).

Both current QEMU SVN and KVM GIT
http://git.kernel.org/?p=linux/kernel/git/avi/kvm-userspace.git;a=blob_plain;f=qemu/target-i386/op_helper.c
have this code for the default wrmsr:

    default:
        /* XXX: exception ? */
        break;
    }


My question was probably phrased the wrong way. I did know where to put
the #GP, but not how to cause it to be delivered inside the machine.


>> (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.

The "Intel 64 and IA-32 Architectures Software Developer's Manual Volume
3B: System Programming Guide, Part 2" says this about MSR 0x8b:
MSR 0x8b: IA32_BIOS_SIGN_ID
MSR/Bit Description:
BIOS Update Signature (RO)
Returns the microcode update signature following the execution of
CPUID.01H. A processor may prevent writing to this MSR when loading
guest states on VM entries or saving guest states on VM exits.
Bit 31:0  Reserved
Bit 63:32 It is recommended that this field be pre-loaded with 0 prior
to executing CPUID. If the field remains 0 following the execution of
CPUID; this indicates that no microcode update is loaded. Any non-zero
value is the microcode update signature.

Unless we want to simulate microcode updates, this can be implemented
easily. I'll send a patch.


There are also a few MSRs we don't implement although they are part of
the common subset of x86/x86-64 MSRs. Then again, if nothing uses them,
no harm is done.


>>> 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.

Where can I look? The QEMU tree in KVM userspace GIT seems to ignore
them as well.
Am I looking at the wrong tree?


>> 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.

Good.


>> 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?

That would work, yes. It will support some cases which are not working
on real hardware, but on the plus side, that approach is a catch-all for
CAR implementations across various CPU generations from Intel and AMD.
I'd recommend to make sure MTRRdefType has default memory type set to UC
(uncacheable) when activating CAR. Otherwise you'd have to use MTRRs to
declare anything except the CAR area as uncached and that may fail due
to alignment requirements.


Regards,
Carl-Daniel

-- 
http://www.hailfinger.org/