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 = ®s->r(ax); break;
- case 1: p = ®s->r(cx); break;
- case 2: p = ®s->r(dx); break;
- case 3: p = ®s->r(bx); break;
- case 4: p = (highbyte_regs ? ®s->ah : (void *)®s->r(sp)); break;
- case 5: p = (highbyte_regs ? ®s->ch : (void *)®s->r(bp)); break;
- case 6: p = (highbyte_regs ? ®s->dh : (void *)®s->r(si)); break;
- case 7: p = (highbyte_regs ? ®s->bh : (void *)®s->r(di)); break;
-#if defined(__x86_64__)
- case 8: p = ®s->r8; break;
- case 9: p = ®s->r9; break;
- case 10: p = ®s->r10; break;
- case 11: p = ®s->r11; break;
- case 12: p = ®s->r12; break;
- case 13: p = ®s->r13; break;
- case 14: p = ®s->r14; break;
- case 15: p = ®s->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
next prev parent 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).