Re: [Xen-devel] [PATCH] x86_emulate adjustments

["Jan Beulich" <jbeulich@xxxxxxxxxx>]

>>> Keir Fraser <keir@xxxxxxxxxxxxx> 05.01.07 15:34 >>>
>On 5/1/07 11:57, "Jan Beulich" <jbeulich@xxxxxxxxxx> wrote:
>
>>> I already got the mis-emulation of x86/64 PUSH/POP with operand-size
>>> override. The stacksz thing I would do differently -- extend the mode input
>>> field to have an extra stack-address-size field. There's another thing
>>> that's not right at the moment -- I think on POP we have to calculate the
>>> operand effective address after adjusting the stack pointer? That is broken
>>> right now which is not a good thing. :-)
>> 
>> The patch sent actually fixes that.
>
>Oh yes, that's neat. But it should increment the effective address by
>op_bytes not by stacksz. stacksz only specifies the stack pointer's width,
>not stack data size.

Indeed, I mixed this up. Makes the code even a little simpler.

>> I finally also want the main one fixed. And yes, there are problems with the
>> prefix decoding, which can possibly be ignored when emulation pv guest insns,
>> but which (in my opinion) should match hardware behavior 1:1 for hvm guests.
>
>I don't see any problem with the existing code w.r.t. what is
>architecturally supported. REX byte must come after all prefix bytes, and
>Intel says that only 4 prefix bytes are allowed. REPNE is not a valid prefix
>on any instruction that the emulator currently supports. If instructions are
>outside these defined boundaries we must have some scope for interpretation?

Okay, I view this differently - if CPUs always behaved a certain way (i.e. REPNE
and REPE being interchangeable as long as the instruction doesn't involve a
comparison) or if behavior is clearly defined (REX followed by non-REX prefix,
where the REX then simply has no effect), the decoder should behave as real
hardware would.

Jan

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel