From: Masami Hiramatsu <masami.hiramatsu.pt@hitachi.com>
To: "Mihai Donțu" <mdontu@bitdefender.com>
Cc: xen-devel@lists.xensource.com, keir@xen.org, jbeulich@suse.com,
Razvan Cojocaru <rcojocaru@bitdefender.com>
Subject: Re: [PATCH 1/3] x86: add support for computing the instruction length
Date: Tue, 09 Sep 2014 19:13:26 +0900 [thread overview]
Message-ID: <540ED2C6.9080900@hitachi.com> (raw)
In-Reply-To: <20140909124431.179b3b25@bitdefender.com>
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@bitdefender.com>
>>
>> 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@hitachi.com
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
next prev parent reply other threads:[~2014-09-09 10:13 UTC|newest]
Thread overview: 21+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-09-09 2:22 [PATCH 0/3] xen: add support for skipping the current instruction Mihai Donțu
2014-09-09 2:28 ` [PATCH 1/3] x86: add support for computing the instruction length Mihai Donțu
2014-09-09 8:47 ` Mihai Donțu
2014-09-09 9:44 ` Mihai Donțu
2014-09-09 10:13 ` Masami Hiramatsu [this message]
2014-09-09 15:46 ` Mihai Donțu
2014-09-09 16:01 ` Mihai Donțu
2014-09-09 16:25 ` Jan Beulich
2014-09-09 17:14 ` Andrew Cooper
2014-09-09 17:27 ` Mihai Donțu
2014-09-09 17:57 ` Konrad Rzeszutek Wilk
2014-09-09 2:29 ` [PATCH 2/3] x86/hvm: implement hvm_get_insn_length() Mihai Donțu
2014-09-09 2:32 ` [PATCH 3/3] xen/tools: script for automatically adjusting the coding style to xen style Mihai Donțu
2014-09-09 14:50 ` Ian Campbell
2014-09-09 15:00 ` Andrew Cooper
2014-09-09 19:52 ` Tim Deegan
2014-09-10 10:59 ` Don Slutz
2014-09-10 14:21 ` Don Slutz
2014-09-09 9:47 ` [PATCH 0/3] xen: add support for skipping the current instruction Jan Beulich
2014-09-09 17:00 ` Mihai Donțu
2014-09-09 18:58 ` Tamas K Lengyel
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=540ED2C6.9080900@hitachi.com \
--to=masami.hiramatsu.pt@hitachi.com \
--cc=jbeulich@suse.com \
--cc=keir@xen.org \
--cc=mdontu@bitdefender.com \
--cc=rcojocaru@bitdefender.com \
--cc=xen-devel@lists.xensource.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.