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. Jan _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
James (song wei)
2009-Dec-02 06:18 UTC
Re: [Xen-devel] mce_wrmsr() and (at least) HVM guests
Jan, IMO, mce_wrmsr() shouldn''t return -1 as a workaround, which leads to a #GP in the guest, at lease in MSR_IA32_MCG_CTL writting. Pnerhaps, it happens with IOMMU ad the GART. -James Song (wei) Jan Beulich wrote:> > 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. > > Jan > > > _______________________________________________ > Xen-devel mailing list > Xen-devel@lists.xensource.com > http://lists.xensource.com/xen-devel > >-- View this message in context: http://old.nabble.com/mce_wrmsr%28%29-and-%28at-least%29-HVM-guests-tp26590226p26604136.html Sent from the Xen - Dev mailing list archive at Nabble.com. _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
>>> "Jan Beulich" <JBeulich@novell.com> 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.Ping? Jan _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
Jiang, Yunhong
2009-Dec-23 03:22 UTC
RE: [Xen-devel] mce_wrmsr() and (at least) HVM guests
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. --jyh>-----Original Message----- >From: Jan Beulich [mailto:JBeulich@novell.com] >Sent: Tuesday, December 22, 2009 9:03 PM >To: Ke, Liping; Jiang, Yunhong >Cc: xen-devel@lists.xensource.com >Subject: Re: [Xen-devel] mce_wrmsr() and (at least) HVM guests > >>>> "Jan Beulich" <JBeulich@novell.com> 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. > >Ping? > >Jan_______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
>>> "Jiang, Yunhong" <yunhong.jiang@intel.com> 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@lists.xensource.com http://lists.xensource.com/xen-devel
Jiang, Yunhong
2010-Jan-04 08:31 UTC
RE: [Xen-devel] mce_wrmsr() and (at least) HVM guests
>-----Original Message----- >From: Jan Beulich [mailto:JBeulich@novell.com] >Sent: Monday, January 04, 2010 4:09 PM >To: Jiang, Yunhong >Cc: Ke, Liping; xen-devel@lists.xensource.com >Subject: RE: [Xen-devel] mce_wrmsr() and (at least) HVM guests > >>>> "Jiang, Yunhong" <yunhong.jiang@intel.com> 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.Hmm, this make sense, originally I thought it''s AMD specific.> >>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.Agree.> >>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).What do you mean of "write zero bits wherever the underlying real register has them clear"?> >>I can cook patches for these issues, after I resolve the vMCE to >>pvops dom0, hopefully early next week. > >That would be great, thanks.I''m working on this now. --jyh> >Jan_______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
>>> "Jiang, Yunhong" <yunhong.jiang@intel.com> 04.01.10 09:31 >>> >>>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). > >What do you mean of "write zero bits wherever the underlying real >register has them clear"?Writing e.g. all 1s into any of these registers doesn''t mean you''d read back all 1s. Hence, writing zero into read-only (always zero) bits should be permitted as well as writing zero into bits that dom0 cleared explicitly. Jan _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel