[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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



On 01/08/16 15:48, Mihai Donțu wrote:
> 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?

Any write to a 32bit GPR zero extends it to 64 bits.  This is specified
by AMD64 and only applies to 32bit writes.  8 and 16 bit writes leave
the upper bits alone.

Therefore movd %mm, %eax will move 32bits from %mm to eax, then zero
extend the upper 32 bits of %rax.

~Andrew

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

 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.