Re: [Xen-devel] how to callback from hypervisor to guest os?

[weiming <zephyr.zhao@xxxxxxxxx>]

Hi Daniel,

Thanks a lot. You confirmed my worries. Event channel may not work for me since I need to call the function in a interrupt handler. 
I'll check out trap injection. I don't know what is this, hope it would be helpful.

Thanks again,
Weiming

On Sun, Jul 6, 2008 at 5:15 AM, Daniel Stodden <stodden@xxxxxxxxxx> wrote:

On Sun, 2008-07-06 at 00:18 -0400, weiming wrote:
> I try to let xen calls a kernel function in guest OS, is it possible?
>
> Here is the detail:
>
> Normally, when a guest hits a fault, the control is transfered to xen.
> Then xen handles the fault and then transfer the control back to
> guest.
>
> For example, in original xen:
> void some_fault_handler()
> {
>
>    ...
>    ...
>    finally, then let guest os handles it
> }
>
> Now, I want to call some guest OS function in xen's handler:
>
> void some_fault_handler()
> {
>
>   guest_func() // a function in guest kernel
>    ...
>    ...
>    finally, then let guest os handles it
> }
>
>
> I can write a module (driver) in guest os, so when guest os boots, I
> can pass the address of my function to xen. My question is that when
> xen calls my function, it needs to swtich to "guest mode". How to do
> this? and when the function call finishes, how to let it come back to
> xen's context?

The way you envision it, i.e. per function pointer, this is just a
mega-bad idea :). While in theory possible, you'd execute arbitrary
insecure (per definition) guest system code at the VMM privilege level.
If at all, it would only work if the calling conventions in Xen and the
guest code match. Beyond that, there's 32/64-bit mixed modes, NPT
translation, and many more reasons not even to consider it.

There's different ways for Xen to communicate with guests. None of them
can give you the simple synchronous calling scheme you suggest.
Reasons include limitations in how the hardware implements control
transfers accross different privilege levels and security/stability
considerations. Even if that were not enough, you would experience some
funny effects in the guest kernel, and an overall hypervisor design
which will just refuse to switch back and forth between VMM and guest
execution.

Have a look at Xen's event channels, trap (interrupt) injections and the
overall shared memory paradigm underlying communications with guests. If
that's what you need, then maybe send a description on what you're
actually up to. :)

hth,
Daniel

--
Daniel Stodden
LRR     -      Lehrstuhl für Rechnertechnik und Rechnerorganisation
Institut für Informatik der TU München             D-85748 Garching
http://www.lrr.in.tum.de/~stodden         mailto:stodden@xxxxxxxxxx
PGP Fingerprint: F5A4 1575 4C56 E26A 0B33  3D80 457E 82AE B0D8 735B

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel