Re: [Qemu-devel] Re: [PATCH 15/15] Implement the bus structure for PAPR virtual IO

[Anthony Liguori <anthony@codemonkey.ws>]

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.
>
>
>
>