Xen devel - Oct 2013 - Hvm_emulate_one() and guest_cpu_user_regs()->eip

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

>>> 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

>> 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.