From: Avi Kivity <avi@redhat.com>
To: Nadav Amit <nadav.amit@gmail.com>
Cc: Takuya Yoshikawa <takuya.yoshikawa@gmail.com>,
"H. Peter Anvin" <hpa@zytor.com>,
Marcelo Tosatti <mtosatti@redhat.com>,
Thomas Gleixner <tglx@linutronix.de>,
Ingo Molnar <mingo@redhat.com>,
x86@kernel.org, kvm@vger.kernel.org,
linux-kernel@vger.kernel.org
Subject: Re: [PATCH] KVM: fix mov immediate emulation for 64-bit operands
Date: Sun, 08 Jan 2012 16:05:20 +0200 [thread overview]
Message-ID: <4F09A2A0.1060801@redhat.com> (raw)
In-Reply-To: <CAKLkAJ4=eT7TdZoOkQKMnhmrESq5kvCQL3Mw52a35gu2yWsNgw@mail.gmail.com>
On 01/08/2012 10:47 AM, Nadav Amit wrote:
> On Sun, Jan 8, 2012 at 3:26 AM, Takuya Yoshikawa
> <takuya.yoshikawa@gmail.com> wrote:
> > Hi,
> >
> > Nadav Amit <nadav.amit@gmail.com> wrote:
> >> On Jan 7, 2012, at 10:25 PM, H. Peter Anvin wrote:
> >>
> >> > On 01/07/2012 12:21 PM, Nadav Amit wrote:
> >> >> MOV immediate instruction (opcodes 0xB8-0xBF) may take 64-bit operand.
> >> >> The previous emulation implementation assumes the operand is no longer than 32.
> >> >>
> >> >> Signed-off-by: Nadav Amit <nadav.amit@gmail.com>
> >> >
> >> > There are exactly two such instructions: MOV immediate (B8-BF) and MOV
> >> > moff (A0-A3); you may want to check the latter too.
> >> >
> >> > -hpa
> >> >
> >>
> >> These instructions (A0-A3) seem to be already covered by the decode_abs function.
> >
> > Like these how about introducing a new flag and change the following entries in the
> > decode table to indicate possible 64bit immediate:
> >
> > /* 0xB8 - 0xBF */
> > X8(I(DstReg | SrcImm | Mov, em_mov)),
> >
> > Checking the opcode byte at the operand decoding stage, like below, does not look nice:
> > (IMO so better ask Avi)
> >
> > + if (size == 8 && ((ctxt->b & 0xF8) != 0xB8 || ctxt->twobyte))
> > size = 4;
> >
>
> I agree. I remembered these flags are expensive (from the time flags
> were set in u32).
> I guess I can add OpImm64.
> Another less preferable alternative is to add a misc. flag or reuse
> another flag.
>
> Avi, please acknowledge adding OpImm64.
Yes, OpImm64 is the cleanest IMO. Note it doesn't even cost us a bit.
--
error compiling committee.c: too many arguments to function
next prev parent reply other threads:[~2012-01-08 14:05 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <1325967346-12539-1-git-send-email-namit@cs.technion.ac.il>
2012-01-07 20:21 ` [PATCH] KVM: fix mov immediate emulation for 64-bit operands Nadav Amit
2012-01-07 20:25 ` H. Peter Anvin
2012-01-08 0:30 ` Nadav Amit
2012-01-08 1:26 ` Takuya Yoshikawa
2012-01-08 8:47 ` Nadav Amit
2012-01-08 14:05 ` Avi Kivity [this message]
2012-01-08 14:08 ` Avi Kivity
2012-01-08 14:44 ` Nadav Amit
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=4F09A2A0.1060801@redhat.com \
--to=avi@redhat.com \
--cc=hpa@zytor.com \
--cc=kvm@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=mingo@redhat.com \
--cc=mtosatti@redhat.com \
--cc=nadav.amit@gmail.com \
--cc=takuya.yoshikawa@gmail.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 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.