From mboxrd@z Thu Jan 1 00:00:00 1970 From: Ben Catterall Subject: Re: RFC on deprivileged x86 hypervisor device models Date: Fri, 17 Jul 2015 16:19:25 +0100 Message-ID: <55A91CFD.8090900@citrix.com> References: <55A8D477.2060909@citrix.com> <55A92B530200007800092802@mail.emea.novell.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; Format="flowed" Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <55A92B530200007800092802@mail.emea.novell.com> List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org To: Jan Beulich Cc: Andrew Cooper , xen-devel@lists.xen.org List-Id: xen-devel@lists.xenproject.org On 17/07/15 15:20, Jan Beulich wrote: >>>> On 17.07.15 at 12:09, wrote: >> Moving between privilege levels >> -------------------------------- >> The general process is to determine if we need to run a device model (or >> similar) and then, if so, switch into deprivileged mode. The operation >> is performed by deprivileged code which calls into the hypervisor as and >> when needed. After the operation completes, we return to the hypervisor. >> >> If deprivileged mode needs to make any hypervisor requests, it can do >> these using a syscall interface, possibly placing an operation code into >> a register to indicate the operation. This would allow it to get data >> to/from the hypervisor. > What I didn't understand from this as well as the individual models' > descriptions is in whose address space the device model is to be > run. Since you're hijacking the vCPU, it sounds like you're intending > Xen's address space to be re-used, just such that the code gets > run at CPL 3. Yep, this will be in Xen's address space using a monitor table patch, mapping in the code for ring 3 execution. > Which would potentially even allow for read-only data > sharing (so that calls back into the hypervisor would be needed only > when data needs to be updated). But perhaps I guessed wrong? Yep, that sounds like a good idea for read-only data. I should be able to do page aliasing for this if I make the data and code page-aligned in their own sections, provided the code is compiled to be position independent and the data is accessed via a pointer. Andrew mentioned mapping in all of Xen's .text section so that I can make use of small helpers. More involved functionality would still need a hypercall due to hardcoded-virtual addresses for data access. > > If not, then method 2 would seem quite a bit less troublesome than > method 1, yet method 3 would (even if more involved in terms of > changes to be done) perhaps result in the most elegant result. I agree that method three is more elegant. If both you and Andrew are ok with going in a per-vcpu stack direction for Xen in general then I'll write a per-vcpu patch first and then do another patch which adds the ring 3 feature on-top of that. > > Again if not, whose runtime environment would the device model > use? It hardly would be qemu you intend to run that way, but > custom code would likely still require some runtime library code to > assist it. Do you mean to re-use hypervisor code for that (perhaps > again utilizing read-only [and executable] data sharing)? > > Jan > Thanks once again, Ben