| |
|
 |
|
 |
|
|
|
| |
|
|
xen-devel
Re: [Xen-devel] [PATCH] x86_emulate adjustments
>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.
>> - synchronize prefix handling with hvm's instrlen determination and about to
>> be committed privileged op decoder (changes coming with the 32on64 patches)
>
>The whole lot of hvm_instrlen/mmio/privop emulators are all going to get
>merged into x86_emulate(). So sync'ing is not really worthwhile, unless
>there are bugs in x86_emulate()'s prefix decoder.
That's actually part of the point of the syncing - after having changed the
others,
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 can't see, however, what value there would particularly be in merging the
privop decoder into x86_emulate - it's pretty orthogonal to the current
functionality there, except for the memory accessed resulting from ins/outs.
To a lesser degree, merging the hvm_instrlen into the main code seems not
desirable for performance reasons, unless you mean to share the lookup table,
but keep the routine separate.
Jan
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel
|
|
|
| |
|
Home