From mboxrd@z Thu Jan  1 00:00:00 1970
From: Avi Kivity <avi@qumranet.com>
Subject: Re: Protected mode transitions and big real mode...
 still an issue
Date: Thu, 15 May 2008 10:33:38 +0300
Message-ID: <482BE752.4080405@qumranet.com>
References: <20080429150236.70c51b02@frecb000711.frec.bull.fr>
	<20080501191331.GA3188@dmt>
	<200805031356.56919.balajirrao@gmail.com>
	<20080505144008.31b7b58c@frecb000711.frec.bull.fr>
	<481F041F.4060103@codemonkey.ws>
	<52d4a3890805050629h21e7fd4aj7f09006ee03b0b5e@mail.gmail.com>
	<20080506153835.0abb550d@frecb000711.frec.bull.fr>
	<48206B94.2060307@codemonkey.ws>
	<52d4a3890805061005v4411fd4fx122e3f6118eb3cb6@mail.gmail.com>
	<20080514092911.561872d4@frecb000711.frec.bull.fr>
	<20080514212953.GA17705@dmt>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Cc: kvm-devel@lists.sourceforge.net,
	Mohammed Gamal <m.gamal005@gmail.com>,
	Guillaume Thouvenin <guillaume.thouvenin@ext.bull.net>
To: Marcelo Tosatti <mtosatti@redhat.com>
Return-path: <kvm-devel-bounces@lists.sourceforge.net>
In-Reply-To: <20080514212953.GA17705@dmt>
List-Unsubscribe: <https://lists.sourceforge.net/lists/listinfo/kvm-devel>,
	<mailto:kvm-devel-request@lists.sourceforge.net?subject=unsubscribe>
List-Archive: <http://sourceforge.net/mailarchive/forum.php?forum_name=kvm-devel>
List-Post: <mailto:kvm-devel@lists.sourceforge.net>
List-Help: <mailto:kvm-devel-request@lists.sourceforge.net?subject=help>
List-Subscribe: <https://lists.sourceforge.net/lists/listinfo/kvm-devel>,
	<mailto:kvm-devel-request@lists.sourceforge.net?subject=subscribe>
Sender: kvm-devel-bounces@lists.sourceforge.net
Errors-To: kvm-devel-bounces@lists.sourceforge.net
List-Id: kvm.vger.kernel.org

Marcelo Tosatti wrote:
> 1) add is storing the result in the wrong register
>
>     6486:       66 64 89 3e 72 01       mov    %edi,%fs:0x172
>     648c:       66 be 8d 03 00 00       mov    $0x38d,%esi
>     6492:       66 c1 e6 04             shl    $0x4,%esi
>     6496:       66 b8 98 0a 00 00       mov    $0xa98,%eax
>     649c:       66 03 f0                add    %eax,%esi
>
> The destination for the add is "%esi", but the emulation stores the 
> result in eax, because:
>
>                 if ((c->d & ModRM) && c->modrm_mod == 3) {
>                         u8 reg;
>                         c->dst.bytes = (c->d & ByteOp) ? 1 : c->op_bytes;
>                         c->dst.ptr = decode_register(c->modrm_rm, c->regs, c->d & ByteOp);
>                 }
>
> modrm_reg contains "6", which is the correct register index, but
> modrm_rm contains 0, so the result is stored in "eax" (see hack).
>   

What version are you looking at?  Current code doesn't have exactly this.

But register-in-modrm decoding is a mess, yes.  I think the best thing 
is to have decode_modrm() accept a struct operand parameter and decode 
into that.

-- 
Do not meddle in the internals of kernels, for they are subtle and quick to panic.


-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft 
Defy all challenges. Microsoft(R) Visual Studio 2008. 
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/