[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
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |