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

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



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

>>> "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

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

> -----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
> 
> 
> 


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

> >>> "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



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

>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

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

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@lists.xensource.com
http://lists.xensource.com/xen-devel

> 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




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

> -----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
> 
> 
> 


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