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

[Ian Campbell <ian.campbell@citrix.com>]

On Fri, 2015-09-04 at 02:33 -0600, Jan Beulich wrote:
> > 
> > > > On 03.09.15 at 18:01, <Ben.Catterall@citrix.com> wrote:
> > 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.
> 
> Just like said for v1: Determining a percentage of overhead is
> pretty meaningless when the actual operation (the I/O port
> access) can take significantly varying amount of time depending
> on which I/O port is being accessed. In particular, considering
> the built in devices emulation of which you want to move out,
> the majority shouldn't actually be doing any accesses to ports
> or MMIO, but just act on RAM. Which hence may take quite a
> bit less than the roughly 1.5us you use as the base line, in turn
> likely resulting in quite a bit higher relative overhead.

Ben says "no port io is actually performed", so I think the 1.5us is purely
the overhead of emulating an I/O access as a NOP.

> 
> That said - even the 350% you determined above look
> prohibitive to me.
> 
> Jan
>