qemu-devel
[Top][All Lists]
Advanced

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

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


From: Anthony Liguori
Subject: Re: [Qemu-devel] Re: [PATCH 15/15] Implement the bus structure for PAPR virtual IO
Date: Sun, 13 Feb 2011 10:52:47 -0600
User-agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.1.15) Gecko/20101027 Lightning/1.0b1 Thunderbird/3.0.10

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.







reply via email to

[Prev in Thread] Current Thread [Next in Thread]