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