On 17/07/15 15:20, Jan Beulich wrote:
On 17.07.15 at 12:09, <ben.catter...@citrix.com> 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@lists.xen.org
http://lists.xen.org/xen-devel