From mboxrd@z Thu Jan 1 00:00:00 1970 From: "James (song wei)" Subject: Re: mce_wrmsr() and (at least) HVM guests Date: Tue, 1 Dec 2009 22:18:12 -0800 (PST) Message-ID: <26604136.post@talk.nabble.com> References: <4B1509BD0200007800022D3B@vpn.id2.novell.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <4B1509BD0200007800022D3B@vpn.id2.novell.com> List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com To: xen-devel@lists.xensource.com List-Id: xen-devel@lists.xenproject.org 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.