From mboxrd@z Thu Jan 1 00:00:00 1970 From: Avi Kivity Subject: Re: KVM: Fix the invlpg instruction emulation on AMD64 Date: Tue, 16 Oct 2007 12:12:18 +0200 Message-ID: <47148E82.9090103@qumranet.com> References: <20071015190823.GA11333@hall.aurel32.net> <47148403.6010603@qumranet.com> <47148867.9070600@aurel32.net> Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Cc: kvm-devel-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org To: Aurelien Jarno Return-path: In-Reply-To: <47148867.9070600-rXXEIb44qovR7s880joybQ@public.gmane.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: kvm-devel-bounces-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org Errors-To: kvm-devel-bounces-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org List-Id: kvm.vger.kernel.org Aurelien Jarno wrote: > Avi Kivity a =E9crit : > = >> Aurelien Jarno wrote: >> = >>> The patch below removes the check for c->modrm_reg =3D=3D 7 to detect t= he = >>> invlpg instruction, as it was the case before before commit = >>> aa38840d3d2e0a804e628077df8d8879b496d741. This fixes the boot of FreeBSD >>> on an AMD64 CPU. >>> >>> It also moves the assignation of c->src.bytes after the test as it is >>> not needed for the invlpg instruction. >>> >>> Signed-off-by: Aurelien Jarno >>> >>> diff --git a/drivers/kvm/x86_emulate.c b/drivers/kvm/x86_emulate.c >>> index fa33fcd..01aa952 100644 >>> --- a/drivers/kvm/x86_emulate.c >>> +++ b/drivers/kvm/x86_emulate.c >>> @@ -824,12 +824,10 @@ modrm_done: >>> c->src.bytes =3D 4; >>> goto srcmem_common; >>> case SrcMem: >>> - c->src.bytes =3D (c->d & ByteOp) ? 1 : >>> - c->op_bytes; >>> /* Don't fetch the address for invlpg: it could be unmapped. */ >>> - if (c->twobyte && c->b =3D=3D 0x01 >>> - && c->modrm_reg =3D=3D 7) >>> + if (c->twobyte && c->b =3D=3D 0x01) >>> break; >>> + c->src.bytes =3D (c->d & ByteOp) ? 1 : c->op_bytes; >>> >>> = >>> = >> I don't understand why this helps. All of the other instructions in = >> this group either have modrm_mod =3D=3D 3 or do require evaluation of th= e = >> = > ^^^^^^^^^ > The test actually concerns modrm_reg and not modrm_mod. Maybe it is wrong? > > = I meant, the instructions all require modrm_mod =3D=3D 3 which means they = reference registers, and not memory. >> source. invlpg is the only one that doesn't. >> = > > I have marked the invlpg instruction the same way as it is done in > kvm-37 to know what happens. I get either modrm_reg =3D 4 or =3D 6 when t= he > invlpg instruction is executed, but never =3D 7. > > = Then it isn't the invlpg instruction at all. Rather smsw (modrm_reg =3D=3D = 4) or lmsw ( =3D=3D 6). I'm confused. (looks) Okay. What we have here is total breakage when emulating an instruction = that uses a mod r/m encoding that actually refers to a register = (modrm_mod =3D=3D 3). In x86_decode_insn() we set src.type as OP_MEM, and = in x86_emulate_insn() we happily fetch it even though it's a register, = generating a fault. It usually doesn't bite us because these instructions are directly executed. The fix is probably to switch to OP_REG if SrcMem and ModRM and = modrm_mod =3D=3D 3 (similarly for DstMem). -- = error compiling committee.c: too many arguments to function ------------------------------------------------------------------------- This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/