From: Gleb Natapov <gleb@redhat.com>
To: Borislav Petkov <bp@alien8.de>
Cc: "Paolo Bonzini" <pbonzini@redhat.com>,
"Andre Przywara" <andre@andrep.de>,
kvm@vger.kernel.org, "Jörg Rödel" <joro@8bytes.org>,
"H. Peter Anvin" <hpa@zytor.com>, x86-ml <x86@kernel.org>
Subject: Re: [PATCH -v2] kvm: Emulate MOVBE
Date: Mon, 22 Apr 2013 12:58:12 +0300 [thread overview]
Message-ID: <20130422095812.GB6027@redhat.com> (raw)
In-Reply-To: <20130422095203.GE4637@pd.tnic>
On Mon, Apr 22, 2013 at 11:52:03AM +0200, Borislav Petkov wrote:
> On Mon, Apr 22, 2013 at 12:42:46PM +0300, Gleb Natapov wrote:
> > > Btw, I wanted to ask: when kvm commits the results, does it look at
> > > ctxt->op_bytes to know exactly how many bytes to write to the guest?
> > > Because if it does, we can save ourselves the trouble here.
> > >
> > > Or does it simply write both the full sizeof(unsigned long) bytes of
> > > ->src.val and ->dst.val to the guest?
> > >
> > No, it does this in case of register operand:
> >
> > static void write_register_operand(struct operand *op)
> > {
> > /* The 4-byte case *is* correct: in 64-bit mode we zero-extend. */
> > switch (op->bytes) {
> > case 1:
> > *(u8 *)op->addr.reg = (u8)op->val;
> > break;
> > case 2:
> > *(u16 *)op->addr.reg = (u16)op->val;
> > break;
> > case 4:
> > *op->addr.reg = (u32)op->val;
> > break; /* 64b: zero-extend */
> > case 8:
> > *op->addr.reg = op->val;
> > break;
> > }
> > }
>
> Ok, and for OP_MEM it does look at ctxt->dst.bytes in writeback(),
> AFAICT. And I see other emulated instructions like POPF, for example, do
> this:
>
> ctxt->dst.bytes = ctxt->op_bytes;
>
> Which means, we can drop all the bullshit in em_movbe and even destroy
> some of the bytes in dst.val but only write out the correct ones. Which
> means, a simpler code and a lot less jumping through hoops.
>
> Would that be the more accepted practice?
>
For most instructions the decoder already sets op->bytes to correct value,
given that all flags a correctly specified in opcode table. Explicit
op->bytes setting should be done only if it cannot be expressed by
opcode flags.
--
Gleb.
next prev parent reply other threads:[~2013-04-22 9:58 UTC|newest]
Thread overview: 48+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-04-09 23:46 [RFC PATCH] Emulate MOVBE Borislav Petkov
2013-04-10 0:03 ` Borislav Petkov
2013-04-10 0:04 ` H. Peter Anvin
2013-04-10 9:53 ` Borislav Petkov
2013-04-10 9:29 ` Andre Przywara
2013-04-10 10:08 ` Gleb Natapov
2013-04-10 10:17 ` Borislav Petkov
2013-04-10 10:21 ` Gleb Natapov
2013-04-10 10:39 ` Andre Przywara
2013-04-10 12:16 ` Gleb Natapov
2013-04-11 0:18 ` [PATCH -v2] kvm: " Borislav Petkov
2013-04-11 14:28 ` Gleb Natapov
2013-04-11 15:37 ` Borislav Petkov
2013-04-14 7:41 ` Gleb Natapov
2013-04-14 17:32 ` Borislav Petkov
2013-04-14 18:36 ` H. Peter Anvin
2013-04-14 19:09 ` Borislav Petkov
2013-04-14 19:40 ` H. Peter Anvin
2013-04-16 17:42 ` Gleb Natapov
2013-04-17 11:04 ` Borislav Petkov
2013-04-17 13:38 ` Gleb Natapov
2013-04-17 14:02 ` Borislav Petkov
2013-04-18 22:48 ` Borislav Petkov
2013-04-21 9:46 ` Gleb Natapov
2013-04-21 11:30 ` Borislav Petkov
2013-04-21 12:51 ` Gleb Natapov
2013-04-23 23:41 ` Borislav Petkov
2013-04-23 23:50 ` H. Peter Anvin
2013-04-24 8:42 ` Gleb Natapov
2013-04-24 8:47 ` Borislav Petkov
2013-04-14 8:43 ` Gleb Natapov
2013-04-14 21:02 ` Borislav Petkov
2013-04-16 11:36 ` Paolo Bonzini
2013-04-21 11:46 ` Borislav Petkov
2013-04-21 12:23 ` Borislav Petkov
2013-04-22 8:53 ` Paolo Bonzini
2013-04-22 9:38 ` Borislav Petkov
2013-04-22 9:42 ` Gleb Natapov
2013-04-22 9:52 ` Borislav Petkov
2013-04-22 9:58 ` Gleb Natapov [this message]
2013-04-22 13:49 ` Borislav Petkov
2013-04-26 16:08 ` Borislav Petkov
2013-04-16 11:47 ` [RFC PATCH] " Paolo Bonzini
2013-04-16 12:08 ` Borislav Petkov
2013-04-16 12:13 ` H. Peter Anvin
2013-04-16 17:28 ` Gleb Natapov
2013-04-17 10:42 ` Paolo Bonzini
2013-04-17 13:33 ` Gleb Natapov
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=20130422095812.GB6027@redhat.com \
--to=gleb@redhat.com \
--cc=andre@andrep.de \
--cc=bp@alien8.de \
--cc=hpa@zytor.com \
--cc=joro@8bytes.org \
--cc=kvm@vger.kernel.org \
--cc=pbonzini@redhat.com \
--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