WARNING - OLD ARCHIVES

This is an archived copy of the Xen.org mailing list, which we have preserved to ensure that existing links to archives are not broken. The live archive, which contains the latest emails, can be found at http://lists.xen.org/
   
 
 
Xen 
 
Home Products Support Community News
 
   
 

xen-devel

Re: [Xen-devel] [PATCH][SVM] remove FFXSR CPUID bit for AMD-V HVM guests

To: xen-devel@xxxxxxxxxxxxxxxxxxx
Subject: Re: [Xen-devel] [PATCH][SVM] remove FFXSR CPUID bit for AMD-V HVM guests
From: "Christoph Egger" <Christoph.Egger@xxxxxxx>
Date: Thu, 1 Feb 2007 17:15:06 +0100
Cc: Jan Beulich <jbeulich@xxxxxxxxxx>, Thomas Woller <thomas.woller@xxxxxxx>
Delivery-date: Thu, 01 Feb 2007 08:15:16 -0800
Envelope-to: www-data@xxxxxxxxxxxxxxxxxx
In-reply-to: <45C21F67.76E4.0078.0@xxxxxxxxxx>
List-help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-id: Xen developer discussion <xen-devel.lists.xensource.com>
List-post: <mailto:xen-devel@lists.xensource.com>
List-subscribe: <http://lists.xensource.com/cgi-bin/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
List-unsubscribe: <http://lists.xensource.com/cgi-bin/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
Organization: AMD / OSRC
References: <45C1B0CB.76E4.0078.0@xxxxxxxxxx> <683860AD674C7348A0BF0DE3918482F6043E190A@xxxxxxxxxxxxxxxxx> <45C21F67.76E4.0078.0@xxxxxxxxxx>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
User-agent: KMail/1.9.4
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




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