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
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel
|
Home