From: Paolo Bonzini <pbonzini@redhat.com>
To: Mason Lee Back <masonleeback@gmail.com>
Cc: "Radim Krčmář" <rkrcmar@redhat.com>,
"Thomas Gleixner" <tglx@linutronix.de>,
"Ingo Molnar" <mingo@redhat.com>,
"H. Peter Anvin" <hpa@zytor.com>,
x86@kernel.org, kvm@vger.kernel.org,
linux-kernel@vger.kernel.org
Subject: Re: [PATCH] kvm: implement VEX prefix decoder, bextr/andn
Date: Fri, 29 Jun 2018 13:47:00 +0200 [thread overview]
Message-ID: <166497ae-c4d8-54f4-55a6-57a5f2c04023@redhat.com> (raw)
In-Reply-To: <20180626121449.30353-1-masonleeback@gmail.com>
Thanks, I have some comments on the decoding logic.
On 26/06/2018 14:14, Mason Lee Back wrote:
> + if (ctxt->b == 0xC4 || ctxt->b == 0xC5) {
This should be exactly the condition that you are removing below:
if ((ctxt->b == 0xc5 || ctxt->b == 0xc4) &&
(mode == X86EMUL_MODE_PROT64 || (ctxt->modrm & 0xc0) == 0xc0))
so that you don't need the "reinterpret as LES or LDS" todo. It should also
be moved earlier, right after done_prefixes. The existing code starting
at
/* Opcode byts(s). */
and ending just before
ctxt->d = opcode.flags;
will become the "else" branch.
Otherwise looks at least... sane. :)
Paolo
> + ctxt->vex.prefix = ctxt->b;
> + if (ctxt->b == 0xC4) {
> + ctxt->vex.value = insn_fetch(u16, ctxt);
> + } else {
> + ctxt->vex.value = insn_fetch(u8, ctxt) << 8;
> + ctxt->vex.r = ctxt->vex.w;
> + ctxt->vex.w = 1;
> + ctxt->vex.x = 1;
> + ctxt->vex.b = 1;
> + ctxt->vex.m = 1;
> + }
>
> - /* vex-prefix instructions are not implemented */
> - if (ctxt->opcode_len == 1 && (ctxt->b == 0xc5 || ctxt->b == 0xc4) &&
> - (mode == X86EMUL_MODE_PROT64 || (ctxt->modrm & 0xc0) == 0xc0)) {
> - ctxt->d = NotImpl;
> + if (mode != X86EMUL_MODE_PROT64 && (!ctxt->vex.r || !ctxt->vex.x)) {
> + /* todo: reinterpret as LES (0xC4) or LDS (0xC5) instruction */
> + return EMULATION_FAILED;
> + }
> +
> + ctxt->rex_prefix |= ctxt->vex.r ? 0 : (1 << 2); /* rex.r */
> + ctxt->rex_prefix |= ctxt->vex.x ? 0 : (1 << 1); /* rex.x */
> + ctxt->rex_prefix |= ctxt->vex.b ? 0 : (1 << 0); /* rex.b */
> + if (mode == X86EMUL_MODE_PROT64 && ctxt->vex.w) {
> + ctxt->op_bytes = 8;
> + }
Please set ctxt->rex_prefix too for consistency.
> +
> + ctxt->b = insn_fetch(u8, ctxt);
> + switch (ctxt->vex.m) {
> + case 1:
> + opcode = twobyte_table[ctxt->b];
"ctxt->opcode_len = 2;" missing here.
> + break;
> + case 2:
> + opcode = opcode_map_0f_38[ctxt->b];
"ctxt->opcode_len = 3;" missing here.
> + break;
> + case 3:
> + /* KVM doesn't support this */
> + return EMULATION_FAILED;
> + default:
> + return EMULATION_FAILED;
> + }
> }
prev parent reply other threads:[~2018-06-29 11:47 UTC|newest]
Thread overview: 2+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-06-26 12:14 Mason Lee Back
2018-06-29 11:47 ` Paolo Bonzini [this message]
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=166497ae-c4d8-54f4-55a6-57a5f2c04023@redhat.com \
--to=pbonzini@redhat.com \
--cc=hpa@zytor.com \
--cc=kvm@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=masonleeback@gmail.com \
--cc=mingo@redhat.com \
--cc=rkrcmar@redhat.com \
--cc=tglx@linutronix.de \
--cc=x86@kernel.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
all inboxes | Powered by JetHome®