xen-devel.lists.xenproject.org archive mirror
 help / color / mirror / Atom feed
From: Andrew Cooper <andrew.cooper3@citrix.com>
To: Xen-devel <xen-devel@lists.xen.org>
Cc: Andrew Cooper <andrew.cooper3@citrix.com>,
	Jan Beulich <JBeulich@suse.com>
Subject: [PATCH v2 2/4] x86/emul: Optimise decode_register() somewhat
Date: Tue, 30 Jan 2018 15:56:10 +0000	[thread overview]
Message-ID: <1517327772-22297-2-git-send-email-andrew.cooper3@citrix.com> (raw)
In-Reply-To: <1517327772-22297-1-git-send-email-andrew.cooper3@citrix.com>

The positions of GPRs inside struct cpu_user_regs doesn't follow any
particular order, so as compiled, decode_register() becomes a jump table to 16
blocks which calculate the appropriate offset, at a total of 207 bytes.

Instead, pre-compute the offsets at build time and use pointer arithmetic to
calculate the result.  By observation, most callers in x86_emulate() inline
and constant-propagate the highbyte_regs value of 0.

The splitting of the general and legacy byte-op cases means that we will now
hit an ASSERT if any code path tries to use the legacy byte-op encoding with a
REX prefix.

Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
---
CC: Jan Beulich <JBeulich@suse.com>

v2:
 * Move byteop_offsets[] into function scope.  Rearrange to have a smaller
   byteop_offsets[] array.
---
 xen/arch/x86/x86_emulate/x86_emulate.c | 75 ++++++++++++++++++++++++----------
 1 file changed, 53 insertions(+), 22 deletions(-)

diff --git a/xen/arch/x86/x86_emulate/x86_emulate.c b/xen/arch/x86/x86_emulate/x86_emulate.c
index ff0a003..123d941 100644
--- a/xen/arch/x86/x86_emulate/x86_emulate.c
+++ b/xen/arch/x86/x86_emulate/x86_emulate.c
@@ -1935,36 +1935,67 @@ load_seg(
     return rc;
 }
 
+/* Map GPRs by ModRM encoding to their offset within struct cpu_user_regs. */
+static const uint8_t cpu_user_regs_gpr_offsets[] = {
+    offsetof(struct cpu_user_regs, r(ax)),
+    offsetof(struct cpu_user_regs, r(cx)),
+    offsetof(struct cpu_user_regs, r(dx)),
+    offsetof(struct cpu_user_regs, r(bx)),
+    offsetof(struct cpu_user_regs, r(sp)),
+    offsetof(struct cpu_user_regs, r(bp)),
+    offsetof(struct cpu_user_regs, r(si)),
+    offsetof(struct cpu_user_regs, r(di)),
+#ifdef __x86_64__
+    offsetof(struct cpu_user_regs, r8),
+    offsetof(struct cpu_user_regs, r9),
+    offsetof(struct cpu_user_regs, r10),
+    offsetof(struct cpu_user_regs, r11),
+    offsetof(struct cpu_user_regs, r12),
+    offsetof(struct cpu_user_regs, r13),
+    offsetof(struct cpu_user_regs, r14),
+    offsetof(struct cpu_user_regs, r15),
+#endif
+};
+
 void *
 decode_register(
     uint8_t modrm_reg, struct cpu_user_regs *regs, int highbyte_regs)
 {
-    void *p;
+    static const uint8_t byteop_offsets[] = {
+        offsetof(struct cpu_user_regs, al),
+        offsetof(struct cpu_user_regs, cl),
+        offsetof(struct cpu_user_regs, dl),
+        offsetof(struct cpu_user_regs, bl),
+        offsetof(struct cpu_user_regs, ah),
+        offsetof(struct cpu_user_regs, ch),
+        offsetof(struct cpu_user_regs, dh),
+        offsetof(struct cpu_user_regs, bh),
+    };
 
-    switch ( modrm_reg )
+    if ( !highbyte_regs )
     {
-    case  0: p = &regs->r(ax); break;
-    case  1: p = &regs->r(cx); break;
-    case  2: p = &regs->r(dx); break;
-    case  3: p = &regs->r(bx); break;
-    case  4: p = (highbyte_regs ? &regs->ah : (void *)&regs->r(sp)); break;
-    case  5: p = (highbyte_regs ? &regs->ch : (void *)&regs->r(bp)); break;
-    case  6: p = (highbyte_regs ? &regs->dh : (void *)&regs->r(si)); break;
-    case  7: p = (highbyte_regs ? &regs->bh : (void *)&regs->r(di)); break;
-#if defined(__x86_64__)
-    case  8: p = &regs->r8;  break;
-    case  9: p = &regs->r9;  break;
-    case 10: p = &regs->r10; break;
-    case 11: p = &regs->r11; break;
-    case 12: p = &regs->r12; break;
-    case 13: p = &regs->r13; break;
-    case 14: p = &regs->r14; break;
-    case 15: p = &regs->r15; break;
-#endif
-    default: BUG(); p = NULL; break;
+        /* Check that the array is a power of two. */
+        BUILD_BUG_ON(ARRAY_SIZE(cpu_user_regs_gpr_offsets) &
+                     (ARRAY_SIZE(cpu_user_regs_gpr_offsets) - 1));
+
+        ASSERT(modrm_reg < ARRAY_SIZE(cpu_user_regs_gpr_offsets));
+
+        /* For safety in release builds.  Debug builds will hit the ASSERT() */
+        modrm_reg &= ARRAY_SIZE(cpu_user_regs_gpr_offsets) - 1;
+
+        return (void *)regs + cpu_user_regs_gpr_offsets[modrm_reg];
     }
 
-    return p;
+    /* Check that the array is a power of two. */
+    BUILD_BUG_ON(ARRAY_SIZE(byteop_offsets) &
+                 (ARRAY_SIZE(byteop_offsets) - 1));
+
+    ASSERT(modrm_reg < ARRAY_SIZE(byteop_offsets));
+
+    /* For safety in release builds.  Debug builds will hit the ASSERT() */
+    modrm_reg &= ARRAY_SIZE(byteop_offsets) - 1;
+
+    return (void *)regs + byteop_offsets[modrm_reg];
 }
 
 static void *decode_vex_gpr(unsigned int vex_reg, struct cpu_user_regs *regs,
-- 
2.1.4


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

  reply	other threads:[~2018-01-30 15:56 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-01-30 15:56 [PATCH v2 1/4] x86/emul: Introduce a test covering legacy byte ops Andrew Cooper
2018-01-30 15:56 ` Andrew Cooper [this message]
2018-01-31 11:09   ` [PATCH v2 2/4] x86/emul: Optimise decode_register() somewhat Jan Beulich
2018-01-30 15:56 ` [PATCH v2 3/4] x86/hvm: Improvements to external users of decode_register() Andrew Cooper
2018-01-30 15:56 ` [PATCH v2 4/4] x86/emul: Improvements to internal " Andrew Cooper
2018-01-31 11:17   ` Jan Beulich
2018-01-31 11:06 ` [PATCH v2 1/4] x86/emul: Introduce a test covering legacy byte ops Jan Beulich
2018-01-31 11:24   ` Andrew Cooper

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=1517327772-22297-2-git-send-email-andrew.cooper3@citrix.com \
    --to=andrew.cooper3@citrix.com \
    --cc=JBeulich@suse.com \
    --cc=xen-devel@lists.xen.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).