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

[Masami Hiramatsu <masami.hiramatsu.pt@xxxxxxxxxxx>]

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!

> 
> Thanks,
> 


-- 
Masami HIRAMATSU
Software Platform Research Dept. Linux Technology Research Center
Hitachi, Ltd., Yokohama Research Laboratory
E-mail: masami.hiramatsu.pt@xxxxxxxxxxx



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