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

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



On Tue, Jul 05, 2016 at 01:58:16PM +0100, George Dunlap wrote:
> On Tue, Jul 5, 2016 at 12:22 PM, Anthony PERARD
> <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.
> >
> > So, would you suggest that I start working on a per-vcpu stack? Or
> > should I continue with the current direction?
> >
> >
> > Some of the code I have, including the code for the benchmark, can be
> > found here:
> > git://xenbits.xen.org/people/aperard/xen-unstable.git
> > branch: hvm-x86-deprivileged-mode-wip
> 
> I think we need to take a step back for a minute.
> 
> Correct me if I'm wrong here: this work doesn't move the *x86
> emulation* code into ring3, but instead moves the *device emulation*
> code into ring3, is that right?

Actually, I think it would be for both. If the impact on performance is
small enough. I haven't try to move the x86 emulation into ring3.

> So the use case would be a device which we think is too complicated to
> emulate in ring0, but is too slow to emulate in qemu.
> 
> So the question is:
> 
> 1. Are there any devices currently in ring0 that we would like to be
> able to move into ring3?
> 2. Are there any devices currently in qemu that we would like to move
> into ring3?

Maybe having the pci root move from qemu to xen would help some use
cases. It has been suggested here:
https://lists.xen.org/archives/html/xen-devel/2016-06/msg00553.html
<alpine.DEB.2.10.1606031724280.2590@sstabellini-ThinkPad-X260>


-- 
Anthony PERARD

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