>>> On 05.07.16 at 13:22, <anthony.per...@citrix.com> 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.2060...@citrix.com>, 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@lists.xen.org https://lists.xen.org/xen-devel