Re: Re: Next steps with pv_ops for Xen

[Jeremy Fitzhardinge <jeremy@goop.org>]

Jan Beulich wrote:
>>> It breaks with:
>>>
>>> Intel machine check architecture supported.
>>> (XEN) traps.c:1734:d0 Domain attempted WRMSR 00000404 from 00000000:00000001 to
>>> ffffffff:ffffffff.
>>> Intel machine check reporting enabled on CPU#0.
>>> general protection fault: 0000 [#1] SMP
>>> Modules linked in:
>>>   
>>>       
>> Hm.  Looks like Xen is getting upset about dom0 trying to disable
>> caching.  No, wait: 0xffffffff:ffffffff?  That's strange; I wonder if
>> its just misreporting the value, because the code doesn't look like its
>> trying to write that.
>>
>> Either way, the fix is to implement xen_write_cr0, and mask off any bits
>> that Xen won't want us to set/clear (or if it doesn't allow dom0 to
>> change cr0, just ignore all updates).
>>     
>
> Why do you think that's a CR0 write? 

Well, the oops says "EIP is at native_write_cr0+0x0/0x4", and the caller
is prepare_set(), which does:

	/*  Enter the no-fill (CD=1, NW=0) cache mode and flush caches. */
	cr0 = read_cr0() | X86_CR0_CD;
	write_cr0(cr0);
	wbinvd();

This is in preparation to setting up the MTRRs, which needs to be all
skipped anyway.

> The messages clearly indicate an
> MSR write, and these writes are clearly visible in intel_p{4,6}_mcheck_init()
> and amd_mcheck_init(). The question is why intel_p4_mcheck_init() doesn't
> check CPUID bits before trying to touch any registers... (And similarly
> amd_mcheck_init() is checking only the MCE bit, not the MCA one.)
>   

The oops and backtrace doesn't suggest it's an MSR write.  Does a crX
write take the same path through the emulator as an MSR write?

> A simple workaround would be to force mce_disabled to 1 in early Xen
> initialization.
>   

That's probably necessary too.

    J