Hvm_emulate_one() and guest_cpu_user_regs()->eip

Hvm_emulate_one() and guest_cpu_user_regs()->eip

[Razvan Cojocaru]

Hello,

I've noticed that an hvm_emulate_one() call (that uses
guest_cpu_user_regs() for it's context) will succeed _without_ modifying
guest_cpu_user_regs()->eip. Again, this is not only happening when
hvm_emulate_one() returns X86EMUL_RETRY (which I'd expect), but also, in
some cases, when it returns no error.

Why would that happen, and what might be an example of an instruction
that could cause that if that's normal behaviour?


Thanks,
Razvan Cojocaru

Re: Hvm_emulate_one() and guest_cpu_user_regs()->eip

[Jan Beulich]

>>> On 17.10.13 at 08:50, Razvan Cojocaru <rzvncj@gmail.com> wrote:
> I've noticed that an hvm_emulate_one() call (that uses
> guest_cpu_user_regs() for it's context) will succeed _without_ modifying
> guest_cpu_user_regs()->eip. Again, this is not only happening when
> hvm_emulate_one() returns X86EMUL_RETRY (which I'd expect), but also, in
> some cases, when it returns no error.
> 
> Why would that happen, and what might be an example of an instruction
> that could cause that if that's normal behaviour?

If you've noticed it, you're in a much better position to tell us for
which instructions this _is_ happening than we are. As for when
this is validly happening - off the top of my head I can only think of
repeated string instructions as candidates (where the progress
being made is expressed in decreasing [RE]CX) or, in similar ways,
LOOPs having their own address as jump target.

Jan

Re: Hvm_emulate_one() and guest_cpu_user_regs()->eip

[Razvan Cojocaru]

>> guest_cpu_user_regs() for it's context) will succeed _without_ modifying
>> guest_cpu_user_regs()->eip. Again, this is not only happening when
>> hvm_emulate_one() returns X86EMUL_RETRY (which I'd expect), but also, in
>> some cases, when it returns no error.
>>
>> Why would that happen, and what might be an example of an instruction
>> that could cause that if that's normal behaviour?
>
> If you've noticed it, you're in a much better position to tell us for
> which instructions this _is_ happening than we are. As for when
> this is validly happening - off the top of my head I can only think of
> repeated string instructions as candidates (where the progress
> being made is expressed in decreasing [RE]CX) or, in similar ways,
> LOOPs having their own address as jump target.

Indeed, the question was actually "what class of instructions might
cause this", not "what instruction is causing my particular issue".
I should have formulated it in clearer terms.

Thank you for your answer.