On 05/04/2012 07:14 PM, Joerg Roedel wrote: > When instruction decoding begins there could be stale values > in the ctxt->memop structure. This causes problems when an > instruction is emulated with more op-bytes then the guest > wants (like the bsr instruction which is always emulated > with 4 or 8 op-bytes). > > The stale value in this structure causes the unit-test for > the bsrw instruction to fail. Initialize the memop.val with > 0 to prevent such bugs (an alternative fix could be to > always emulate instructions with the number of op-bytes > requested by the guest). > > > diff --git a/arch/x86/kvm/emulate.c b/arch/x86/kvm/emulate.c > index d4bf50c..1b516ec 100644 > --- a/arch/x86/kvm/emulate.c > +++ b/arch/x86/kvm/emulate.c > @@ -3937,6 +3937,7 @@ int x86_decode_insn(struct x86_emulate_ctxt *ctxt, void *insn, int insn_len) > struct opcode opcode; > > ctxt->memop.type = OP_NONE; > + ctxt->memop.val = 0; > ctxt->memopp = NULL; > ctxt->_eip = ctxt->eip; > ctxt->fetch.start = ctxt->_eip; This only works for long sized values - it doesn't initialize val64 on i386, for example. So I think it's better to change bsr (and family) to use emualte_2op_SrcV_nobyte() instead (which has the added benefit of using the same values as the processor for the "undefined" bits). -- error compiling committee.c: too many arguments to function -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
