[PATCH][SVM] remove FFXSR CPUID bit for AMD-V HVM guests

[PATCH][SVM] remove FFXSR CPUID bit for AMD-V HVM guests

[Woller, Thomas]

[-- Attachment #1: Type: text/plain, Size: 397 bytes --]

Remove visibility of the FFXSR CPUID bit to an HVM guest.
This patch allows HVM Windows x64 to install/boot on AMD-V platforms.

This patches applies cleanly to xen-unstable 13743.

Please apply to xen-unstable/3.0.5.
If possible, pls apply to xen-3.0.4-testing. 

 
  --Tom

thomas.woller@amd.com
AMD Corporation
5204 E. Ben White Blvd. UBC1
Austin, Texas 78741
+1-512-602-0059


[-- Attachment #2: svm_cpuid_ffxsr_13743.patch --]
[-- Type: application/octet-stream, Size: 1221 bytes --]

diff -r 54678a99e102 xen/arch/x86/hvm/svm/svm.c
--- a/xen/arch/x86/hvm/svm/svm.c	Wed Jan 31 12:23:35 2007 +0000
+++ b/xen/arch/x86/hvm/svm/svm.c	Wed Jan 31 16:52:42 2007 -0600
@@ -1189,6 +1189,8 @@ static void svm_vmexit_do_cpuid(struct v
         /* So far, we do not support 3DNow for the guest. */
         clear_bit(X86_FEATURE_3DNOW & 31, &edx);
         clear_bit(X86_FEATURE_3DNOWEXT & 31, &edx);
+        /* no FFXSR instructions feature. */
+        clear_bit(X86_FEATURE_FFXSR & 31, &edx);
     }
     else if ( input == 0x80000007 || input == 0x8000000A )
     {
diff -r 54678a99e102 xen/include/asm-x86/cpufeature.h
--- a/xen/include/asm-x86/cpufeature.h	Wed Jan 31 12:23:35 2007 +0000
+++ b/xen/include/asm-x86/cpufeature.h	Wed Jan 31 16:52:21 2007 -0600
@@ -92,6 +92,7 @@
 #define X86_FEATURE_LAHF_LM	(6*32+ 0) /* LAHF/SAHF in long mode */
 #define X86_FEATURE_CMP_LEGACY	(6*32+ 1) /* If yes HyperThreading not valid */
 #define X86_FEATURE_SVME        (6*32+ 2) /* Secure Virtual Machine */
+#define X86_FEATURE_FFXSR       (6*32+25) /* FFXSR instruction optimizations */
 
 #define cpu_has(c, bit)		test_bit(bit, (c)->x86_capability)
 #define boot_cpu_has(bit)	test_bit(bit, boot_cpu_data.x86_capability)

[-- Attachment #3: Type: text/plain, Size: 138 bytes --]

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

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

[Jan Beulich]

>>> "Woller, Thomas" <thomas.woller@amd.com> 01.02.07 00:06 >>>
>Remove visibility of the FFXSR CPUID bit to an HVM guest.
>This patch allows HVM Windows x64 to install/boot on AMD-V platforms.

Would you mind explaining why this is necessary? (Similarly I have a hard
time understanding why 3dnow can't be allowed for hvm guests.)

Jan

RE: [PATCH][SVM] remove FFXSR CPUID bit for AMD-V HVM guests

[Petersson, Mats]

 

> -----Original Message-----
> From: xen-devel-bounces@lists.xensource.com 
> [mailto:xen-devel-bounces@lists.xensource.com] On Behalf Of 
> Jan Beulich
> Sent: 01 February 2007 08:20
> To: Woller, Thomas
> Cc: xen-devel@lists.xensource.com
> Subject: Re: [Xen-devel] [PATCH][SVM] remove FFXSR CPUID bit 
> for AMD-V HVM guests
> 
> >>> "Woller, Thomas" <thomas.woller@amd.com> 01.02.07 00:06 >>>
> >Remove visibility of the FFXSR CPUID bit to an HVM guest.
> >This patch allows HVM Windows x64 to install/boot on AMD-V platforms.
> 
> Would you mind explaining why this is necessary? (Similarly I 
> have a hard
> time understanding why 3dnow can't be allowed for hvm guests.)

I don't know why FFXSR shouldn't be allowed... 

3Dnow! should be allowed in the guest, however, MMIO from SSE/3Dnow!/MMX
instructions would fail - but that's no reason to disallow 3DNow!

--
Mats
> 
> Jan
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xensource.com
> http://lists.xensource.com/xen-devel
> 
> 
> 

RE: [PATCH][SVM] remove FFXSR CPUID bit for AMD-V HVM guests

[Woller, Thomas]

> >>> "Woller, Thomas" <thomas.woller@amd.com> 01.02.07 00:06 >>>
> >Remove visibility of the FFXSR CPUID bit to an HVM guest.
> >This patch allows HVM Windows x64 to install/boot on AMD-V platforms.
> 
> Would you mind explaining why this is necessary? (Similarly I 
> have a hard time understanding why 3dnow can't be allowed for 
> hvm guests.)
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.

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.  

tom

RE: [PATCH][SVM] remove FFXSR CPUID bit for AMD-V HVM guests

[Jan Beulich]

>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

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

[Christoph Egger]

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

RE: [PATCH][SVM] remove FFXSR CPUID bit for AMD-V HVM guests

[Woller, Thomas]

> Then I'd favor this change over the posted one.
I'm not against this change, we just haven't done any testing on it.
And getting close to 3.0.5 =testing time.  For now, this allows winx64
to install/boot w/ less risk, albeit both might be small.  We can remove
FFSRC CPUID maxsking, and then fixup gpfault check on FFSRX and give it
a week or 2 of testing, then post patch.

> 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.
Thanks. would be good to try this out if it's easy... 

Now that I think about it, we did have a problem with movq to/from XMM
register instructions, when using a K7 optimized linux kernel in the
guest.  I can't recall if masking the 3dNOW! Bits helped that failure,
that specific kernel might have just ignored the CPUID bits anyway.
Hmmm.  Travis might remember a bit better.. So, CC'ing him on this
thread.

We've been bitten before with emulation problems, due to the need to
perform additional emulation in AMD-V.
tom

RE: [PATCH][SVM] remove FFXSR CPUID bit for AMD-V HVM guests

[Petersson, Mats]

 

> -----Original Message-----
> From: xen-devel-bounces@lists.xensource.com 
> [mailto:xen-devel-bounces@lists.xensource.com] On Behalf Of 
> Woller, Thomas
> Sent: 01 February 2007 16:30
> To: Jan Beulich; Egger, Christoph; Betak, Travis
> Cc: xen-devel@lists.xensource.com
> Subject: RE: [Xen-devel] [PATCH][SVM] remove FFXSR CPUID bit 
> for AMD-V HVM guests
> 
> > Then I'd favor this change over the posted one.
> I'm not against this change, we just haven't done any testing on it.
> And getting close to 3.0.5 =testing time.  For now, this allows winx64
> to install/boot w/ less risk, albeit both might be small.  We 
> can remove
> FFSRC CPUID maxsking, and then fixup gpfault check on FFSRX 
> and give it
> a week or 2 of testing, then post patch.
> 
> > 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.
> Thanks. would be good to try this out if it's easy... 
> 
> Now that I think about it, we did have a problem with movq to/from XMM
> register instructions, when using a K7 optimized linux kernel in the
> guest.  I can't recall if masking the 3dNOW! Bits helped that failure,
> that specific kernel might have just ignored the CPUID bits anyway.
> Hmmm.  Travis might remember a bit better.. So, CC'ing him on this
> thread.

Movq is would normally be an MMX rather than XMM (aka SSE) register.
Movdq is the SSE instruction to use. 

But you're probably right that a kernel optimized for a K7/K8 processor
would most likely ignore checking if the processor model supports the
instruction, as that is sort of the whole idea of telling the kernel
build which processor you have... Otherwise all code has to have two
versions, one for K7 (or whatever) and one not. 

 > 
> We've been bitten before with emulation problems, due to the need to
> perform additional emulation in AMD-V.

Yes, that's my fault, eh? ;-)

--
Mats
> tom
> 
> 
> 
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xensource.com
> http://lists.xensource.com/xen-devel
> 
> 
>