All of lore.kernel.org
 help / color / mirror / Atom feed
From: Andrew Cooper <andrew.cooper3@citrix.com>
To: Jan Beulich <JBeulich@suse.com>,
	xen-devel <xen-devel@lists.xenproject.org>
Cc: Keir Fraser <keir@xen.org>
Subject: Re: [PATCH 2/2] x86emul: simplify asm() constraints
Date: Tue, 10 Mar 2015 19:48:38 +0000	[thread overview]
Message-ID: <54FF4A96.9030008@citrix.com> (raw)
In-Reply-To: <54FF2B9402000078000683B8@mail.emea.novell.com>


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

On 10/03/15 16:36, Jan Beulich wrote:
> Use + on outputs instead of = and a matching input. Allow not just
> memory for the _eflags operand (it turns out that recent gcc produces
> worse code when also doing this for _dst.val, so the latter is being
> avoided).
>
> Signed-off-by: Jan Beulich <jbeulich@suse.com>
>
> --- a/xen/arch/x86/x86_emulate/x86_emulate.c
> +++ b/xen/arch/x86/x86_emulate/x86_emulate.c
> @@ -428,7 +428,7 @@ typedef union {
>  /* Before executing instruction: restore necessary bits in EFLAGS. */
>  #define _PRE_EFLAGS(_sav, _msk, _tmp)                           \
>  /* EFLAGS = (_sav & _msk) | (EFLAGS & ~_msk); _sav &= ~_msk; */ \
> -"movl %"_sav",%"_LO32 _tmp"; "                                  \
> +"movl %"_LO32 _sav",%"_LO32 _tmp"; "                            \
>  "push %"_tmp"; "                                                \
>  "push %"_tmp"; "                                                \
>  "movl %"_msk",%"_LO32 _tmp"; "                                  \
> @@ -448,7 +448,7 @@ typedef union {
>  "pushf; "                                       \
>  "pop  %"_tmp"; "                                \
>  "andl %"_msk",%"_LO32 _tmp"; "                  \
> -"orl  %"_LO32 _tmp",%"_sav"; "
> +"orl  %"_LO32 _tmp",%"_LO32 _sav"; "
>  
>  /* Raw emulation: instruction has two explicit operands. */
>  #define __emulate_2op_nobyte(_op,_src,_dst,_eflags,_wx,_wy,_lx,_ly,_qx,_qy)\
> @@ -460,18 +460,16 @@ do{ unsigned long _tmp;                 
>              _PRE_EFLAGS("0","4","2")                                       \
>              _op"w %"_wx"3,%1; "                                            \
>              _POST_EFLAGS("0","4","2")                                      \
> -            : "=m" (_eflags), "=m" ((_dst).val), "=&r" (_tmp)              \
> -            : _wy ((_src).val), "i" (EFLAGS_MASK),                         \
> -              "m" (_eflags), "m" ((_dst).val) );                           \
> +            : "+g" (_eflags), "+m" ((_dst).val), "=&r" (_tmp)              \
> +            : _wy ((_src).val), "i" (EFLAGS_MASK) );                       \

I believe the old ASM was buggy, not just inefficient.

Having read the Extended ASM documentation quite carefully, the
following statement is relevant

"Only input operands may use numbers in constraints, and they must each
refer to an output operand. Only a number (or the symbolic assembler
name) in the constraint can guarantee that one operand is in the same
place as another. The mere fact tha|t 'foo' |||is the value of both
operands is not enough to guarantee that they are in the same place in
the generated assembler code."

Because the input operands do not use numbers, the asm must read from %5
and write to %0 to guarantee that the _eflags temporary is used properly.

I believe that this transformation does now make the asm correct, as the
output and input sides are now guaranteed to match the %0 used to
reference the _eflags temporary.

Did you observe any code changes simply from changing = constraints to
+, or did we get very lucky in with the generated code?

I think it might be a very wise idea to switch to using symbolic names. 
This code is very complicated and has many ways to go subtly wrong.

~Andrew

[-- Attachment #1.2: Type: text/html, Size: 4001 bytes --]

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

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

  reply	other threads:[~2015-03-10 19:48 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-03-10 16:30 [PATCH 0/2] x86emul: XSA-123 follow-up Jan Beulich
2015-03-10 16:35 ` [PATCH 1/2] x86emul: drop unused "bigval" fields from struct operand Jan Beulich
2015-03-10 18:47   ` Andrew Cooper
2015-03-10 16:36 ` [PATCH 2/2] x86emul: simplify asm() constraints Jan Beulich
2015-03-10 19:48   ` Andrew Cooper [this message]
2015-03-11  8:08     ` Jan Beulich
2015-03-12 10:42   ` Tim Deegan
2015-03-12 10:55     ` Jan Beulich

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=54FF4A96.9030008@citrix.com \
    --to=andrew.cooper3@citrix.com \
    --cc=JBeulich@suse.com \
    --cc=keir@xen.org \
    --cc=xen-devel@lists.xenproject.org \
    /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.