Re: [Xen-devel] [PATCH v3 2/3] x86/emulate: add support of emulating SSE2 instruction {, v}movd mm, r32/m32 and {, v}movq mm, r64

[Mihai Donțu <mdontu@xxxxxxxxxxxxxxx>]

On Monday 01 August 2016 07:43:20 Jan Beulich wrote:
> > > > Your suggestion makes sense, but I'm starting to doubt my initial
> > > > patch. :-) I'm testing "movq xmm1, xmm1" and noticing that it takes the
> > > > GPR-handling route and I can't seem to be able to easily prevent it
> > > > with !(rex_prefix & REX_B), as rex_prefix == 0 and vex.b == 1. I need
> > > > to take a harder look at how that class of instructions is coded.    
> > > 
> > > You obviously need to distinguish the two kinds of register sources/
> > > destinations: GPRs need suitable re-writing of the instruction (without
> > > having looked at the most recent version of the patch yet I btw doubt
> > > converting register to memory operands is the most efficient model),
> > > while MMs, XMMs, and YMMs can retain their register encoding.  
> > 
> > Regarding efficiency, I'm not married with the approach I've proposed.
> > If you can give me a few more hints, I can give it a try.  
> 
> I'd rather pick a fixed register and update the regs->... field from that
> after the stub was executed. E.g. using rAX and treating it just like a
> return value of the "call". But maybe I'm imagining this easier than it
> really is; as an alternative I'd then suggest really following what Andrew
> said - use a pointer into regs->, not mmvalp. But (as said in the review
> mail) you'd then have the problem of the missing zero-extension for
> writes to 32-bit GPRs

I thought that by re-using (hijacking, really) mmvalp, the patch will
look less intrusive and thus not add too much to an already complex
code.

Assuming I'll just pass to the stub "a"(ea.reg), would it be a good
idea to just zero-out the 64bit register before that? It does not
appear to be any instructions that write just the low dword. Or am I
misunderstanding the zero-extension concept?

-- 
Mihai DONȚU

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
https://lists.xen.org/xen-devel