7 messages in com.xensource.lists.xen-develRe: [Xen-devel] [PATCH] x86_emulate a...| From | Sent On | Attachments |
|---|---|---|
| Jan Beulich | 05 Jan 2007 02:03 | |
| Keir Fraser | 05 Jan 2007 03:24 | |
| Jan Beulich | 05 Jan 2007 03:57 | |
| Keir Fraser | 05 Jan 2007 04:04 | |
| Keir Fraser | 05 Jan 2007 06:33 | |
| Jan Beulich | 05 Jan 2007 06:50 | |
| Keir Fraser | 05 Jan 2007 07:04 |
| Subject: | Re: [Xen-devel] [PATCH] x86_emulate adjustments |
|---|---|
| From: | Jan Beulich (jbeu...@novell.com) |
| Date: | 01/05/2007 03:57:33 AM |
| List: | com.xensource.lists.xen-devel |
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-...@lists.xensource.com http://lists.xensource.com/xen-devel