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

Re: [Xen-devel] [RFC] Hypervisor, x86 emulation deprivileged



>>> On 05.07.16 at 13:22, <anthony.perard@xxxxxxxxxx> wrote:
> Hi,
> 
> I've taken over the work from Ben to have a deprivileged mode in the
> hypervisor, but I'm unsure about which direction to take.
> 
> First, after understanding what have been done, and fixing a few things,
> I did some benchmark to compare a simple "device" running in ring0 to
> the same one running in ring3 and also in QEMU. This "device" would call
> 'rdtsc' on 'outl' and return the value in 'inl' (I actually do not use
> the value). The measurement is done from a kernel module in the guest
> (simply rdtsc;inl;rdtsc multiple time). This is the result I've found:
> 
>     ring3 ~3.5x slower than ring0
>     qemu   ~22x slower than ring0
>           ~6.5x slower than ring3
> 
> So that would be the worst-case scenario, where an emulator barely do
> anything.
> 
> 
> There have been different methods proposed to do the depriv mode, in
> <55A8D477.2060909@xxxxxxxxxx>, one of which was to implement a per-vcpu
> stack which could be more elegant.

Sadly my mail frontend doesn't let me search for message IDs (and
this old a mail would have been purged anyway meanwhile), so I
think (also considering how much time has passed) it would be better
if you actually summarized where things stopped back then.

> So, would you suggest that I start working on a per-vcpu stack? Or
> should I continue with the current direction?

Was there any reason why using per-vCPU stacks would be assumed
to meaningfully improve above numbers? I'm not sure pursuing this
idea is really useful if more than a marginal performance degradation
results.

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
https://lists.xen.org/xen-devel

 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.