| |
|
 |
|
 |
|
|
|
| |
|
|
xen-devel
Re: [Xen-devel] Re: Next steps with pv_ops for Xen
|
To: |
"Juan Quintela" <juan.quintela@xxxxxxxxx>, "Jeremy Fitzhardinge" <jeremy@xxxxxxxx> |
|
Subject: |
Re: [Xen-devel] Re: Next steps with pv_ops for Xen |
|
From: |
"Jan Beulich" <jbeulich@xxxxxxxxxx> |
|
Date: |
Tue, 27 Nov 2007 08:30:57 +0000 |
|
Cc: |
"xen-devel@xxxxxxxxxxxxxxxxxxx" <xen-devel@xxxxxxxxxxxxxxxxxxx>, Eduardo Habkost <ehabkost@xxxxxxxxxx>, Juan Quintela <quintela@xxxxxxxxxx>, "Stephen C. Tweedie" <sct@xxxxxxxxxx>, Glauber de Oliveira Costa <gcosta@xxxxxxxxxx>, Chris Wright <chrisw@xxxxxxxxxxxx>, "virtualization@xxxxxxxxxxxxxx" <virtualization@xxxxxxxxxxxxxx> |
|
Delivery-date: |
Tue, 27 Nov 2007 00:30:35 -0800 |
|
Envelope-to: |
www-data@xxxxxxxxxxxxxxxxxx |
|
In-reply-to: |
<474B15FC.4050901@xxxxxxxx> |
|
List-help: |
<mailto:xen-devel-request@lists.xensource.com?subject=help> |
|
List-id: |
Xen developer discussion <xen-devel.lists.xensource.com> |
|
List-post: |
<mailto:xen-devel@lists.xensource.com> |
|
List-subscribe: |
<http://lists.xensource.com/cgi-bin/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe> |
|
List-unsubscribe: |
<http://lists.xensource.com/cgi-bin/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe> |
|
References: |
<1195682725.6726.48.camel@xxxxxxxxxxxxxxxxxxxxx> <4744BB54.4040803@xxxxxxxx> <de87b960711260602m799b365fw62af3976913d64cc@xxxxxxxxxxxxxx><de87b960711260602m799b365fw62af3976913d64cc@xxxxxxxxxxxxxx> <474B15FC.4050901@xxxxxxxx> |
|
Sender: |
xen-devel-bounces@xxxxxxxxxxxxxxxxxxx |
>> 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? 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.)
But then I just noticed that Xen itself doesn't clear the MCE/MCA bits either
in emulate_forced_invalid_op(), apparently under the assumption that PV
guests wouldn't try to make use of this feature.
A simple workaround would be to force mce_disabled to 1 in early Xen
initialization.
Jan
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel
|
|
|
| |
|
Home