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

[Xen-devel] MAX_INST_LEN?


  • To: Xen-devel@xxxxxxxxxxxxxxxxxxx
  • From: "Petersson, Mats" <Mats.Petersson@xxxxxxx>
  • Date: Fri, 7 Apr 2006 19:37:48 +0200
  • Delivery-date: Fri, 07 Apr 2006 11:19:00 -0700
  • List-id: Xen developer discussion <xen-devel.lists.xensource.com>
  • Thread-index: AcZaZ9ezDXyOXSt+QAGWoky+0sYlqAAAGYPw
  • Thread-topic: MAX_INST_LEN?

In xen/include/asm-x86/hvm/io.h there is a definition for MAX_INST_LEN,
which is currently defined to 32. 

The x86 spec says that any instruction longer than 15 bytes is invalid
(The processor gives General Protection fault if the instruction is
longer than 15 bytes - something that can only be achieved with
redundant prefixing). 

So, my question is: Is there ANY OTHER reason why this shouldn't be 15
(or possibly 16 if you want to have a nice even 2^n number)?

By the way, I don't see any particular problem[1] it being 32, I just
noticed it when I started printing my buffer for the instruction when
trying to figure out if I was decoding something correctly, and I
expected to get a short line of bytes, but it overflowed the edge of my
screen by some fair amount - since it was 32 bytes, rather than my
expectation of 15-16 bytes.

Of course, there is a minor curiosity in that the svm.c uses a different
constant, MAX_INST_SIZE for ONE case of copying code from the guest.
This constant is 15. Every other piece of code copying instructions is
using the MAX_INST_LEN... 

[1]It would of course have some minor performance impact (especially
since it's also filled with zero's before we copy the code in - and then
check that we filled the entire buffer ;-) ), but I think there's plenty
of other things to performance enhance before we start saving bytes
being copied from the guest when analyzing instructions... 

--
Mats


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