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

From: "Mihai Donțu" <mdontu@bitdefender.com>
To: Andrew Cooper <andrew.cooper3@citrix.com>
Cc: Zhi Wang <zhi.a.wang@intel.com>, Jan Beulich <JBeulich@suse.com>,
	xen-devel@lists.xen.org
Subject: Re: [PATCH v3 2/3] x86/emulate: add support of emulating SSE2 instruction {, v}movd mm, r32/m32 and {, v}movq mm, r64
Date: Mon, 1 Aug 2016 18:10:51 +0300	[thread overview]
Message-ID: <20160801181051.547a4b4e@bitdefender.com> (raw)
In-Reply-To: <82a9354b-8a21-da20-634f-094b9162847c@citrix.com>

[-- Attachment #1.1: Type: text/plain, Size: 1580 bytes --]

On Monday 01 August 2016 15:53:56 Andrew Cooper wrote:
> On 01/08/16 15:48, Mihai Donțu wrote:
> > > 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.

... and given that the stub has (%rAX) as destination, the
zero-extension is not implicit and I have to do it myself. Which also
means two of my tests in a previous patch are wrong (0xbdbdbdbdffffffff
checks). Darn! :-)

-- 
Mihai DONȚU

[-- Attachment #1.2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 181 bytes --]

[-- Attachment #2: Type: text/plain, Size: 127 bytes --]

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