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

["Woller, Thomas" <thomas.woller@xxxxxxx>]

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