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

[Fabio Fantoni <fabio.fantoni@m2r.biz>]

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@citrix.com>
>
>
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xen.org/xen-devel