From mboxrd@z Thu Jan 1 00:00:00 1970 From: "Jan Beulich" Subject: RE: [PATCH][SVM] remove FFXSR CPUID bit for AMD-V HVM guests Date: Thu, 01 Feb 2007 16:12:07 +0000 Message-ID: <45C21F67.76E4.0078.0@novell.com> References: <45C1B0CB.76E4.0078.0@novell.com> <683860AD674C7348A0BF0DE3918482F6043E190A@SAUSEXMB1.amd.com> Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <683860AD674C7348A0BF0DE3918482F6043E190A@SAUSEXMB1.amd.com> Content-Disposition: inline List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com To: Thomas Woller Cc: xen-devel@lists.xensource.com List-Id: xen-devel@lists.xenproject.org >There is no known issue with FFSRX at this time, an alternative (that >works) is to modify the code in long_mode_do_msr_write() to not gp fault >on FFSRX bit being set (this was the original failure). > > if ( msr_content & ~(EFER_FFSRX | EFER_LME | EFER_LMA | EFER_NX >| EFER_SCE) ) > { > gdprintk(XENLOG_WARNING, "Trying to set reserved bit in " > "EFER: %"PRIx64"\n", msr_content); > goto gp_fault; > } > >The above code also allows windows to continue installation and function >seemingly properly. Then I'd favor this change over the posted one. >So, to answer your Q, there is not a particular known failure case for >3DNow! Or FFSRX disablement - the issue would be that there has been no >directed testing effort concerning 3DNow and FFSRX usages in the guest >to determine if would be any issues per se. For FFSRX, I can't see what issues you would expect. For 3dnow, it's as good (or as bad) as other MMX or XMM stuff trying to access MMIO, I would guess: if any of this is used anywhere, I guess some updates to emulation might be needed. Jan