From mboxrd@z Thu Jan 1 00:00:00 1970 From: Avi Kivity Subject: Re: [PATCH 2/2] KVM: x86 emulator: Discard CR2 in x86 emulator Date: Thu, 15 Nov 2007 12:15:20 +0200 Message-ID: <473C1C38.4000700@qumranet.com> References: <200711151532.20558.sheng.yang@intel.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Cc: kvm-devel-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org To: Sheng Yang Return-path: In-Reply-To: <200711151532.20558.sheng.yang-ral2JQCrhuEAvxtiuMwx3w@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 Sheng Yang wrote: > From 9cd9d5cde7341d5e9de41b1070cea7a98e7d8cc9 Mon Sep 17 00:00:00 2001 > From: Sheng Yang > Date: Thu, 15 Nov 2007 15:11:58 +0800 > Subject: [PATCH 2/2] KVM: x86 emulator: Discard CR2 in x86 emulator > > For CR2 is unreliable and unavailable in many condition, this patch > completely decode memory operand instead of using CR2 in x86 emulator. > > > One of my innermost wishes... > diff --git a/drivers/kvm/x86.c b/drivers/kvm/x86.c > index aa6c3d8..85a0776 100644 > --- a/drivers/kvm/x86.c > +++ b/drivers/kvm/x86.c > @@ -1293,7 +1293,7 @@ int emulate_instruction(struct kvm_vcpu *vcpu, > > vcpu->emulate_ctxt.vcpu = vcpu; > vcpu->emulate_ctxt.eflags = kvm_x86_ops->get_rflags(vcpu); > - vcpu->emulate_ctxt.cr2 = cr2; > + vcpu->emulate_ctxt.memop = 0; > We have c->modrm_ea which can be used for the memory operand. > diff --git a/drivers/kvm/x86_emulate.c b/drivers/kvm/x86_emulate.c > index c020010..95536a8 100644 > --- a/drivers/kvm/x86_emulate.c > +++ b/drivers/kvm/x86_emulate.c > @@ -880,6 +880,8 @@ done_prefixes: > break; > } > c->src.type = OP_MEM; > + ctxt->memop = insn_fetch(u32, c->src.bytes, c->eip); > + c->eip -= c->src.bytes; /* keep the page fault ip */ > I don't understand this. In the cases where the memory operand address is encoded in the instruction, we fetch it explicity. When it isn't, this is broken. > break; > case SrcImm: > c->src.type = OP_IMM; > @@ -918,14 +920,18 @@ done_prefixes: > c->twobyte && (c->b == 0xb6 || c->b == 0xb7)); > break; > case DstMem: > + c->dst.bytes = (c->d & ByteOp) ? 1 : c->op_bytes; > This seems unrelated; needs a separate patch. Please check that movzx and movsx aren't affected by this. > /* > * For instructions with a ModR/M byte, switch to register > * access if Mod = 3. > */ > - if ((c->d & ModRM) && c->modrm_mod == 3) > + if ((c->d & ModRM) && c->modrm_mod == 3) { > c->dst.type = OP_REG; > - else > - c->dst.type = OP_MEM; > + break; > + } > + c->dst.type = OP_MEM; > + ctxt->memop = insn_fetch(u32, c->dst.bytes, c->eip); > + c->eip -= c->dst.bytes; /* keep the page fault ip */ > Ditto. -- 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/