All of lore.kernel.org
 help / color / mirror / Atom feed
From: Andrew Cooper <andrew.cooper3@citrix.com>
To: "Mihai Donțu" <mdontu@bitdefender.com>,
	"Jan Beulich" <JBeulich@suse.com>
Cc: Zhi Wang <zhi.a.wang@intel.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 15:53:56 +0100	[thread overview]
Message-ID: <82a9354b-8a21-da20-634f-094b9162847c@citrix.com> (raw)
In-Reply-To: <20160801174833.5a20f846@bitdefender.com>

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@lists.xen.org
https://lists.xen.org/xen-devel

  reply	other threads:[~2016-08-01 14:53 UTC|newest]

Thread overview: 26+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-08-01  2:52 [PATCH v3 1/3] x86/emulate: add support for {, v}movq xmm, xmm/m64 Mihai Donțu
2016-08-01  2:52 ` [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
2016-08-01  9:52   ` Andrew Cooper
2016-08-01 12:53     ` Mihai Donțu
2016-08-01 12:56       ` Mihai Donțu
2016-08-01 12:57       ` Andrew Cooper
2016-08-01 12:59       ` Jan Beulich
2016-08-01 13:28         ` Mihai Donțu
2016-08-01 13:43           ` Jan Beulich
2016-08-01 14:48             ` Mihai Donțu
2016-08-01 14:53               ` Andrew Cooper [this message]
2016-08-01 15:10                 ` Mihai Donțu
2016-08-01 14:55               ` Mihai Donțu
2016-08-01 14:59                 ` Jan Beulich
2016-08-01 15:01                   ` Andrew Cooper
2016-08-01 14:56               ` Jan Beulich
2016-08-01 13:38   ` Jan Beulich
2016-08-01  2:52 ` [PATCH v3 3/3] x86/emulate: added tests for {, v}movd mm, r32/m32 and {, v}movq xmm, r64/m64 Mihai Donțu
2016-08-01  9:54   ` Andrew Cooper
2016-08-01 12:46     ` Mihai Donțu
2016-08-01  9:18 ` [PATCH v3 1/3] x86/emulate: add support for {, v}movq xmm, xmm/m64 Andrew Cooper
2016-08-01 13:19 ` Jan Beulich
2016-08-01 13:25   ` Mihai Donțu
2016-08-01 23:19   ` Mihai Donțu
2016-08-02  6:19     ` Jan Beulich
2016-08-02  8:13       ` Mihai Donțu

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=82a9354b-8a21-da20-634f-094b9162847c@citrix.com \
    --to=andrew.cooper3@citrix.com \
    --cc=JBeulich@suse.com \
    --cc=mdontu@bitdefender.com \
    --cc=xen-devel@lists.xen.org \
    --cc=zhi.a.wang@intel.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.