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

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


  • To: Jan Beulich <jbeulich@xxxxxxxxxx>
  • From: Keir Fraser <keir@xxxxxxxxxxxxx>
  • Date: Fri, 05 Jan 2007 14:34:02 +0000
  • Cc: xen-devel@xxxxxxxxxxxxxxxxxxx
  • Delivery-date: Fri, 05 Jan 2007 06:33:49 -0800
  • List-id: Xen developer discussion <xen-devel.lists.xensource.com>
  • Thread-index: Accw1os1ybks7pzJEduFdAAX8io7RQ==
  • Thread-topic: [Xen-devel] [PATCH] x86_emulate adjustments

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.

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

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