On 02/13/2011 10:17 AM, Benjamin Herrenschmidt wrote:
On Sun, 2011-02-13 at 13:40 +0100, Alexander Graf wrote:
We can surely move it to dynamic later on. I think the "proper" way
would be to populate a qdev bus and have the individual hypercall
receivers register themselves through -device creations. But Blue
really is the expert here :).
Why would you want to go through a bus for all hcalls ? (ie including
the ones that aren't device related ?). That doesn't quite "tick" but
I'm sure I'm missing part of the picture here :-)
A virtual bus is just an interface. If all virtual devices that
interact via hcalls would all reside on the same virtual bus, then
having hypercalls registered through that interface makes sense because
you can associate hypercalls with particular devices. This means that
you can automatically deregister on device removal and things like that.
But I don't think this will work out well. I think treating the
hypercalls as a simple dispatch table just like ioport would make sense.
Regards,
Anthony Liguori
A simple dispatch table based approach is the most efficient and simple
way to do that (after a switch/case) in my opinion, this is more/less
what we have done internally, with a pair of calls for "modules" to
register hcalls if they need to. The hcalls numbers are fixed and
specified in sPAPR.
BTW. We are still missing in this picture RTAS. I suppose David is still
cleaning up those patches. Basically, we use a 5 instruction trampoline
that calls a private h-call, the RTAS emulation is entirely in qemu.
This has to be done that way for various reasons, but essentially RTAS
under pHyp also more/less turns into private pHyp calls under the hood.
Cheers,
Ben.
