[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




Hi Fabio,

On 04/09/15 11:46, Fabio Fantoni wrote:
[snip]

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?

So, QEMU emulates devices for HVM guests. Now, letting the portio operation through to QEMU to emulate takes about 20e-6 seconds. But, that includes the time QEMU takes to actually emulate the port operation so is not the 'pure' overhead. I need to do more detailed analysis to get that figure.

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?

We're using sysret and syscall already to do the transition which are the fast system call operations. I don't have actual benchmark values for their execution time though. We map the depriv code, stack and data sections into the monitor table when initialising the HVM guest (user mode mapping) so Xen doesn't need to worry about those mappings whilst executing a depriv operation.

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?
I'm not quite sure what you're asking here, sorry! Are you asking if we can take an HVM guest instruction, analyse it to determine if it's safe to execute and then execute it rather than emulating it? If so:

QEMU handles device emulation and this is deliberately not done in Xen to reduce the attack surface of the hypervisor and keep it minimal. We do need to analyse instructions at some points (x86 emulate) but this is error prone (there's a paper or two on exploits of this feature). This is one of the reasons for considering a depriv mode in the first pace, by moving such code into a deprivileged area, we can prevent a bug in this code from leading to hypervisor compromise. I'm not aware of any future hardware or set of instructions but that doesn't mean there aren't/won't be!

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.
np, I hope I've understood correctly!


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