Re: [Xen-devel] [PATCH 0/3] xen: add support for skipping the current instruction

["Jan Beulich" <JBeulich@xxxxxxxx>]

>>> On 09.09.14 at 04:22, <mdontu@xxxxxxxxxxxxxxx> wrote:
> RÄzvan Cojocaru has posted a patch in July that added support for
> computing the length of the instruction that generated the VMEXIT:
> 
> http://lists.xen.org/archives/html/xen-devel/2014-07/msg00314.html 
> 
> which he then split into two in order to give himself more time to
> think about Andrew's proposal to extend the existent x86 emulator. I
> offered to take that off his hands as he was already working to get
> several patches in.
> 
> The initial code was an almost verbatim copy from Linux, with a very
> small change to make it compile within xen (replaced 'asm/string.h'
> with 'xen/string.h').
> 
> I spent some time to determine what the code save would be if we were
> to make use of existent xen functionality and my first impression is
> that the increase in complexity of an already very complex machinery
> (caused by both the nature of the architecture and by the design of the
> emulator itself) would not make it worthwhile.
> 
> The starting point would be x86_emulate() which uses a carefully coded
> switch() to walk through the opcode groups, but it only covers a subset
> of those and, obviously, expects one to add not just instruction length
> calculation (ie. next eip/rip) but also _actual_ emulation to which I
> don't think anyone can commit given the architecture complexity (think
> MMX, SSEn, AVXn etc). The opportunity for bugs makes this task rather
> prohibitive.

I disagree, for two reasons: First, there's no reason to implement full
emulation for everything as long as there's a way for the caller to
know whether actual emulation (rather than just instruction boundary
determination) did happen. And second, as recently also pointed out
by Andrew, making full emulation (including very recent additions like
AVX-512) a goal would likely be of more than just theoretical value
(allowing emergency migration of guests to less capable hosts without
prior CPU feature leveling). Plus - as long as those newer extensions
could be emulated in ways similar by how the FPU instructions get
dealt with, I think the scope for bugs can be meaningfully reduced.

> Masami Hiramatsu, the author of the Linux code, most likely came to the
> same realization and used a rather simple approach: created
> x86-opcode-map.txt in which he simply lists the opcode classes in a
> fairly human readable way. Then he uses an awk script to generate the
> core of the machinery to which he added a couple of helper functions. I
> decided to keep this part and see if I can replace some of the helpers,
> but aside insn_fetch_bytes() which relies on previous calculations made
> in x86_emulate(), I wasn't able to identify any other code-reuse
> opportunities. Also, I don't yet have the courage to shuffle code
> around in x86_emulate.c. :-)
> 
> In conclusion, I would opt to bring Masami's code in with very little
> changes possible (other than coding style which can be handled by a
> script) so that future updates can be easily ported to xen.
> 
> What follows are three patches:
>   1. adds Masami's et al code (insn_get_length());
>   2. adds a user in emulate.c;
>   3. a clang-format script that can be used to do the bulk of the
>   coding style work on the imported files (should someone else other
>   than me were to do it).
> 
> The motivation behind the 'instruction skipping' idea is to allow
> memory introspection technologies to instruct Xen to jump over
> instructions that reside in memory areas of the guest that are marked
> as NX in EPT (eg. heap/stack of user processes). In such situations,
> maintaining the vCPU register state is not needed and, as a bonus,
> expedites the termination of the in-guest process that attempted to
> execute the code.

Leaving open why terminating the in-guest process requires advancing
its IP then, if all other register updates are unnecessary. A huge chunk
of source code like this needs - I think - a little more of a rationale than
some exotic, only partially explained use case.

Jan

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