Re: [Xen-devel] RFC on deprivileged x86 hypervisor device models

[Ben Catterall <Ben.Catterall@xxxxxxxxxx>]

On 17/07/15 15:20, Jan Beulich wrote:
> > > > On 17.07.15 at 12:09, <Ben.Catterall@xxxxxxxxxx> 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

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