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

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


  • To: xen-devel@xxxxxxxxxxxxxxxxxxx
  • From: Mihai DonÈu <mdontu@xxxxxxxxxxxxxxx>
  • Date: Tue, 9 Sep 2014 05:22:41 +0300
  • Comment: DomainKeys? See http://domainkeys.sourceforge.net/
  • Delivery-date: Tue, 09 Sep 2014 02:23:11 +0000
  • Domainkey-signature: a=rsa-sha1; q=dns; c=nofws; s=default; d=bitdefender.com; b=k7ZjqT40rZbgyqK/aDS2nj5jaYWNhtY4jWXX6IgZZvVKiSfE2W0QiPeW7kdN1pVVI2LXtbdI0oEA9Oq5+GkpsVZC1PCtzg1WPmt3ptVS3o+jz4xBQNMkWS6uD4DMsoi7qZApOmcZPGMioqy13g5r5JO8xdAw6GF2MkfOLGwguoHo/zF3Y/qpIHOmzT+TNk+mtkeK82lE0+BXTum3W/TVFlsp2yX9GylyD1xjPSBYbhSojbqoE1MLCKsLci8yJgA5biGFth6iO4kAdeiDrhvzv568VAHyYCtFlQlYF8VQoWNtd6WzwHZtfMqhock9fM3axccZsSSeSo8tNRThp+jbYA==; h=Received:Received:Received:Received:Received:Date:From:To:Subject:Message-ID: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>

Hi,

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.

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.

Thanks,

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