[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


  • To: Jan Beulich <jbeulich@xxxxxxxxxx>, <xen-devel@xxxxxxxxxxxxxxxxxxx>
  • From: Keir Fraser <keir@xxxxxxxxxxxxx>
  • Date: Fri, 05 Jan 2007 11:25:20 +0000
  • Delivery-date: Fri, 05 Jan 2007 03:25:04 -0800
  • List-id: Xen developer discussion <xen-devel.lists.xensource.com>
  • Thread-index: AccwvC7FbUMH7JyvEduFdAAX8io7RQ==
  • Thread-topic: [Xen-devel] [PATCH] x86_emulate adjustments

On 5/1/07 10:03, "Jan Beulich" <jbeulich@xxxxxxxxxx> wrote:

> - don't provide cmpxchg8b emulation where not needed (i.e. page table ops on
> 64-bit hv)

With the cmpxchg16b changes this probably makes sense, despite my dislike of
ifdef if it can be avoided. I'll take a look.

> - properly deal with stack operands (push/pop)

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

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

> - support cmpxchg16b if the CPU supports it

I'll take a look at this part. Sounds sensible.

 Thanks,
 Keir


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


 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.