From mboxrd@z Thu Jan  1 00:00:00 1970
From: "Christoph Egger" <Christoph.Egger@amd.com>
Subject: Re: [PATCH][SVM] remove FFXSR CPUID bit for AMD-V
	HVM guests
Date: Thu, 1 Feb 2007 17:15:06 +0100
Message-ID: <200702011715.06740.Christoph.Egger@amd.com>
References: <45C1B0CB.76E4.0078.0@novell.com>
	<683860AD674C7348A0BF0DE3918482F6043E190A@SAUSEXMB1.amd.com>
	<45C21F67.76E4.0078.0@novell.com>
Mime-Version: 1.0
Content-Type: text/plain;
 charset=iso-8859-1
Content-Transfer-Encoding: 7bit
Return-path: <xen-devel-bounces@lists.xensource.com>
In-Reply-To: <45C21F67.76E4.0078.0@novell.com>
Content-Disposition: inline
List-Unsubscribe: <http://lists.xensource.com/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com
To: xen-devel@lists.xensource.com
Cc: Jan Beulich <jbeulich@novell.com>, Thomas Woller <thomas.woller@amd.com>
List-Id: xen-devel@lists.xenproject.org

On Thursday 01 February 2007 17:12, Jan Beulich wrote:
> >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.

mplayer uses SIMD instructions pretty heavy for video decoding.
But I can't say if this leads to MMIO accesses w/o investigation.

Christoph