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

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



Il 03/09/2015 18:01, Ben Catterall ha scritto:
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.

Sorry for my stupid questions:
Is there a test with benchmark using qemu instead for know how is different? Qemu seems that emulate also some istructions cases that xen hypervisor doesn't for now, or I'm wrong?

Is there any possible hardware technology or set of instructions for improve the operations also deprivileged or transition from Xen is obliged to control even mappings memory access? Is there any possible future hardware technology or set of instructions for take needed informations from hypervisor for executing directly all needed checks, them if ok and any possible exceptions/protections or delegate this to xen for each instruction with a tremendous impact on the efficiency can not be improved? If I said only absurd things because of my knowledge too low about sorry for having wasted your time.

Thanks for any reply and sorry for my bad english.


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


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