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

["Petersson, Mats" <Mats.Petersson@xxxxxxx>]

> -----Original Message-----
> From: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx 
> [mailto:xen-devel-bounces@xxxxxxxxxxxxxxxxxxx] On Behalf Of 
> Woller, Thomas
> Sent: 01 February 2007 16:30
> To: Jan Beulich; Egger, Christoph; Betak, Travis
> Cc: xen-devel@xxxxxxxxxxxxxxxxxxx
> 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@xxxxxxxxxxxxxxxxxxx
> http://lists.xensource.com/xen-devel
> 
> 
> 



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