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

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

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)?


Thanks once again,

Xen-devel mailing list



Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.