RE: [Xen-devel] mce_wrmsr() and (at least) HVM guests

["Jan Beulich" <JBeulich@xxxxxxxxxx>]

>>> "Jiang, Yunhong" <yunhong.jiang@xxxxxxxxx> 23.12.09 04:22 >>>
>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.

I tend to disagree, based on the "and/or implementation specific": As
long as model specific information is available to the kernel, it may
validly write other values - as is happening for the specific AMD case.

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

I agree here.

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

I don't think so, as per the above.

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

Yes, this would make sense, albeit it seems overkill to me - there
shouldn't really be disagreement in how specific models get handled.
Instead, perhaps an unprivileged guest should be permitted to write
zero bits wherever the underlying real register has them clear (as
read back from hardware, not as written by Xen or dom0).

>I can cook patches for these issues, after I resolve the vMCE to
>pvops dom0, hopefully early next week.

That would be great, thanks.

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel