Jan, sorry for no response for this. It is not in my inbox, maybe is put into
my junkmail box. (Really strange that some xen-devel mail will be put into
junkmail, including my patch submission mail).
I think it is different for MCG_CTL and MCn_CTL:
For MCG_CTL, the SDM spec stated: "IA32_MCG_CTL controls the reporting of
machine-check exceptions. If present, writing 1s to this register enables
machine-check features and writing all 0s disables machine-check features. All
other values are undefined and/or implementation specific.". So I assume
current implementation is ok.
For MCn_CTL, the spec only stated that "P6 family processors only allow the
writing of all 1s or all 0s to the IA32_MCi_CTL MSR". So yes, current
implementation is over-killed, especially I think we should not care about P6
family in Xen environment.
But the mce_cpu_quirks() give remind me if we should still split the Intel/AMD
MCE msr virtualization? For example, will AMD platform allow IA32_MCE_CTL to be
not all 1s and 0s?
And also another potential issue raised out. For example, guest has clear one
bit in MCn_CTL while physically it is enabled. If a error corresponding to this
bit really happen, at least we should not inject a vMCE to guest. We will
either kill the guest, or let the guest continues, depends on the error type .
I can cook patches for these issues, after I resolve the vMCE to pvops dom0,
hopefully early next week.
>From: Jan Beulich [mailto:JBeulich@xxxxxxxxxx]
>Sent: Tuesday, December 22, 2009 9:03 PM
>To: Ke, Liping; Jiang, Yunhong
>Subject: Re: [Xen-devel] mce_wrmsr() and (at least) HVM guests
>>>> "Jan Beulich" <JBeulich@xxxxxxxxxx> 01.12.09 12:19 >>>
>>With mce_wrmsr() not permitting to write other than all zeroes or all ones
>>to MCG_CTL and MCn_CTL, it is not possible for guests to implement
>>workarounds (see the one in mce_cpu_quirks() which has been present in
>>Linux versions for a very long time). While one could expect PV guests to
>>be aware of that (and avoid the workaround), HVM guests clearly can't
>>be expected to. Thus the question is whether the handling should be
>>made a little more permissive.
>>Initially I had thought of just making Xen check whether the bit(s) in
>>question are also off in the physical MSR, but that would imply that
>>Xen always has implemented at least all of the workarounds any guest
>>may know of. I'm not sure I have a good other idea, short of allowing
>>all writes to succeed.
Xen-devel mailing list