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

Re: [Xen-devel] [PATCH 1/3] x86: add support for computing the instruction length


  • To: Masami Hiramatsu <masami.hiramatsu.pt@xxxxxxxxxxx>
  • From: Mihai DonÈu <mdontu@xxxxxxxxxxxxxxx>
  • Date: Tue, 9 Sep 2014 18:46:30 +0300
  • Cc: xen-devel@xxxxxxxxxxxxxxxxxxx, keir@xxxxxxx, jbeulich@xxxxxxxx, Razvan Cojocaru <rcojocaru@xxxxxxxxxxxxxxx>
  • Comment: DomainKeys? See http://domainkeys.sourceforge.net/
  • Delivery-date: Tue, 09 Sep 2014 15:46:47 +0000
  • Domainkey-signature: a=rsa-sha1; q=dns; c=nofws; s=default; d=bitdefender.com; b=pFljCu+/PuHP5wYsq0DzhJDDMpKFb06OSvfbKgCSC7sdPvQSW+BwPPpSpWSGGN3QhzUMFohxcQWu0rh8iLT+H6tu3XFRtzGJMDtOWNABtFV9K0TXCwdU3WbrrTNlbxtRMzoPT5GmqJ9esXKU+2H/J1Fz+LV2Gngrqwj3xsebmRJwmMG0GPLO6j+iR8dkF2QjtqAYjwwDEJ6k9J6FmEKfm6YYEO77lEwBVzEUIemz4PR9Jxko9UtCskiSIMXoDxVy6ktzWv9y+PlOpRWmIDoiLU6aRvSCaN1x+KxrpVkVJZjuEW3oJsW+O1TZb1nOQZCMNVxZ7qm5sne95I7yw01Yrg==; h=Received:Received:Received:Received:Received:Date:From:To:Cc:Subject:Message-ID:In-Reply-To:References:Organization:MIME-Version:Content-Type:Content-Transfer-Encoding:X-BitDefender-Scanner:X-BitDefender-Spam:X-BitDefender-SpamStamp:X-BitDefender-CF-Stamp;
  • List-id: Xen developer discussion <xen-devel.lists.xen.org>

On Tuesday 09 September 2014 19:13:26 Masami Hiramatsu wrote:
> Hello,
> 
> (2014/09/09 18:44), Mihai DonÈu wrote:
> > On Tue, 9 Sep 2014 11:47:05 +0300 Mihai DonÈu wrote:
> >> On Tuesday 09 September 2014 05:28:02 Mihai DonÈu wrote:
> >>> This patch adds support for computing the length of an instruction. The 
> >>> entire
> >>> logic relies on a set of opcode tables generated by gen-insn-attr-x86.awk 
> >>> from
> >>> x86-opcode-map.txt and a number of small helper functions. It originated 
> >>> in
> >>> Linux, where it was added by Masami Hiramatsu. Since it's an almost 
> >>> identical
> >>> copy, it's separated from the x86 emulator, simplifying future updates.
> >>>
> >>> ---
> >>> Changed since v1:
> >>>   * adjusted the coding style to match the rest of xen
> >>>   * moved the source files into x86/x86_emulate
> >>>   * replaced inat-tables.c with x86-opcode-map.txt and 
> >>> gen-insn-attr-x86.awk
> >>>     that are used to generate it
> >>>
> >>> Signed-off-by: Mihai DonÈu <mdontu@xxxxxxxxxxxxxxx>
> >>
> >> There are a couple of design issues with this code which Jan pointed
> >> out and which I overlooked. I'm sorry, it was not intentional. I'll do
> >> my best to address them in a following email.
> > 
> > I'd like to give it a try at saving some time by asking the author
> > behind the Linux code what is his opinion on this.
> > 
> > Masami, I'm trying to bring to xen the code you wrote for Linux a while
> > back and which uses an opcode map, a script and some helper functions
> > (insn.c, inat.c) to compute an instruction's length. Jan has made some
> > observations which I believe would be of interest to the kernel
> > developers as well. Please see:
> > 
> > http://lists.xenproject.org/archives/html/xen-devel/2014-07/msg00375.html
> 
> Ah, thanks for the comments!
> 
> > 
> > While valid, would they affect the overall goal of insn_get_length() or
> > is that function tuned for a specific use case? I can't yet tell for
> > sure if we can get away with it.
> 
> Actually, in the Linux kernel, currently we use this just for decoding the
> length and searching branches. Thus, strict decoding is not needed (moreover,
> I have a request to optimize it only for that purpose for speeding up).
> But I think it is better to integrate several different decoders in kernel 
> too.
> So your comments are very useful for me! :)

Thank you Masami, that's the exact same use case we plan for it too: to
solely compute the instruction length. This, I hope, dispels any
concerns regarding its functionality and whether it does what it's
supposed to do correctly.

-- 
Mihai DonÈu

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel

 


Rackspace

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