On 06/26/2012 11:30 AM, Gleb Natapov wrote:
>> >
>> > Where will you put those for instance: interruptibility, have_exception,
>> > perm_ok, only_vendor_specific_insn and how can they not be initialized
>> > before each instruction emulation?
>>
>> x86_emulate_ops::get_interruptibility()
>> x86_emulate_ops::set_interruptibility()
>> x86_emulate_ops::exception()
>>
> They do not remove the need for initialization before instruction
> execution, they just move things that need to be initialized somewhere
> else (to kvm_arch_vcpu likely).
>
>> x86_decode_insn(struct x86_insn_ctxt *ctxt, unsigned flags)
>> {
>> ctxt->flags = flags;
>> ctxt->perm_ok = false;
>> }
>>
>> In short, instruction emulation state is only seen by instruction
>> emulation functions, the others don't get to see it.
>>
> So you want to divide emulator.c to two types of function: those without
> side effect, that do some kind of calculations on vcpu state according
> to weird x86 rules, and those that change vcpu state and write it back
> eventually. I do not see the justification for that complication really.
> emulator.c is complicated enough already and the line between two may be
> blurred.
Really, the only issue is that the read/write callbacks sometimes cannot
return a result. Otherwise the entire thing would be stateless.
> If you dislike linearize() callback so much I can make
> kvm_linearize_address() to do calculation base on its parameters only.
> It is almost there, only cpl and seg base/desc are missing from
> parameter list. I can put it into header and x86.c/emulator.c will both
> be able to use it.
And all the stack mask and stuff? Yuck.
--
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
