Re: [RFC] Hypervisor, x86 emulation deprivileged

From: George Dunlap <george.dunlap@citrix.com>
To: Anthony PERARD <anthony.perard@citrix.com>
Cc: Andrew Cooper <andrew.cooper3@citrix.com>,
	Paul Durrant <paul.durrant@citrix.com>,
	Jan Beulich <jbeulich@suse.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [RFC] Hypervisor, x86 emulation deprivileged
Date: Tue, 5 Jul 2016 13:58:16 +0100	[thread overview]
Message-ID: <CAFLBxZb+QBstj4MgYQFJUat_TvoGKVQZw+DkgYSQd4SAHp2Mkg@mail.gmail.com> (raw)
In-Reply-To: <20160705112227.GA1729@perard.uk.xensource.com>

On Tue, Jul 5, 2016 at 12:22 PM, Anthony PERARD
<anthony.perard@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.2060909@citrix.com>, 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?

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?

 -George

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