[Xen-devel] [PATCH RFC v2 0/4] HVM x86 deprivileged mode operations

[Ben Catterall <Ben.Catterall@xxxxxxxxxx>]

Hi all,

I have made requested changes and reworked the patch series based on the
comments recieved. Thank you to all of the contributors to those discussions!
The next step will be to provide an example of usage of this system which
will follow in another patch.

The main changes from v1 are:
 - No longer copying the privileged Xen stack but instead change the
   interrupt/exception, syscall and sysenter pointers to be below the current
   execution point.
 - AMD SVM support
 - Stop IST copying onto the privileged stack
 - Watchdog timer to kill a long running deprivileged domain
 - Support for crashing a domain whilst performing a deprivileged operation
 - .text section is now aliased
 - Assembly updates
 - Updated deprivileged context switching code to fix bugs
 - Moved processor-specific code to processor-specific files
 - Reduction of user stack sizes
 - Updates to interfaces and an is_hvm_deprivileged_mode() style test
 - Small bug fixes
 - Revised performance tests

Many thanks in advance,
Ben

The aim of this work is to create a proof-of-concept to establish if it is
feasible to move certain Xen operations into a deprivileged context to mitigate
the impact of a bug or compromise in such areas. An example would be x86_emulate
or virtual device emulation which is not done in QEMU for performance reasons.

Performance testing
-------------------
Performance testing indicates that the overhead for this deprivileged mode
depend heavily upon the processor. This overhead is the cost of moving into
deprivileged mode and then fully back out of deprivileged mode. The conclusions
are that the overheads are not negligible and that operations using this
mechanism would benefit from being long running or be high risk components. It
will need to be evaluated on a case-by-case basis.

I performed 100000 writes to a single I/O port on an Intel 2.2GHz Xeon
E5-2407 0 processor and an AMD Opteron 2376. This was done from a python script
within the HVM guest using time.time() and running Debian Jessie. Each write was
trapped to cause a vmexit and the time for each write was calculated. The port
operation is bypassed so that no portio is actually performed. Thus, the
differences in the measurements below can be taken as the pure overhead. These
experiments were repeated. Note that only the host and this HVM guest were
running (both Debian Jessie) during the experiments.

Intel Intel 2.2GHz Xeon E5-2407 0 processor:
--------------------------------------------
1.55e-06 seconds was the average time for performing the write without the
         deprivileged code running.

5.75e-06 seconds was the average time for performing the write with the
         deprivileged code running.

So approximately 351% overhead

AMD Opteron 2376:
-----------------
1.74e-06 seconds was the average time for performing the write without the
         deprivileged code running.
3.10e-06 seconds was the average time for performing the write with an entry and
         exit from deprvileged mode.

So approximately 178% overhead.

Signed-off-by: Ben Catterall <Ben.Catterall@xxxxxxxxxx>


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