Avi Kivity wrote:
> Yang, Sheng wrote:
>>> From ebfc23b71051e5ab19d22fb3f9c3d57721566ea9 Mon Sep 17 00:00:00
2001
>> From: Sheng Yang <[EMAIL PROTECTED]>
>> Date: Fri, 26 Oct 2007 13:41:28 +0800
>> Subject: [PATCH] KVM: x86_emulator: Decode the memory operand for
'mov'
>>
>> For the following TPR patch, we must get gva for executing
instructions.
>> Most memory operands are decoded in ModR/M part, except some kinds of
>> 'mov'. This patch decoded the memory operand for these 'mov'
instructions,
>> instead of using CR2.
>>
>> Signed-off-by: Sheng Yang <[EMAIL PROTECTED]>
>> ---
>> drivers/kvm/x86_emulate.c | 11 +++++++++++
>> 1 files changed, 11 insertions(+), 0 deletions(-)
>>
>> diff --git a/drivers/kvm/x86_emulate.c b/drivers/kvm/x86_emulate.c
index
>> f858c01..f75f75a 100644 --- a/drivers/kvm/x86_emulate.c
>> +++ b/drivers/kvm/x86_emulate.c
>> @@ -837,6 +837,11 @@ modrm_done:
>> && c->modrm_reg == 7)
>> break;
>> srcmem_common:
>> + /* Decode memory operand for mov(0xa0 ... 0xa1)*/
>> + if ((c->b == 0xa0) || (c->b == 0xa1)) {
>> + ctxt->cr2 = insn_fetch(u32, c->src.bytes,
>> c->eip);
>> + c->eip -= c->src.bytes;
>> + }
>>
>
> We're moving eip backwards here, then forwards in
x86_emulate_insn()...
> I'm getting dizzy.
>
> How about add a MemAbs bitflag in decode it outside, similar to the
> ModRM flag and decoding?
Oops...
In current condition, no eip move required. I will remove these
movement...
Thanks
Yang, Sheng
-------------------------------------------------------------------------
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/
_______________________________________________
kvm-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/kvm-devel
