From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from [140.186.70.92] (port=44886 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1PofBu-0001ia-4Y for qemu-devel@nongnu.org; Sun, 13 Feb 2011 11:52:55 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1PofBs-00013m-PV for qemu-devel@nongnu.org; Sun, 13 Feb 2011 11:52:53 -0500 Received: from mail-gx0-f173.google.com ([209.85.161.173]:42540) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1PofBs-00013i-Lw for qemu-devel@nongnu.org; Sun, 13 Feb 2011 11:52:52 -0500 Received: by gxk28 with SMTP id 28so1920488gxk.4 for ; Sun, 13 Feb 2011 08:52:52 -0800 (PST) Message-ID: <4D580C5F.2060506@codemonkey.ws> Date: Sun, 13 Feb 2011 10:52:47 -0600 From: Anthony Liguori MIME-Version: 1.0 Subject: Re: [Qemu-devel] Re: [PATCH 15/15] Implement the bus structure for PAPR virtual IO References: <1297522467-5975-1-git-send-email-david@gibson.dropbear.id.au> <1297522467-5975-16-git-send-email-david@gibson.dropbear.id.au> <1BA55C28-0AAF-46A5-A14F-04B0B61419DB@suse.de> <1297544424.14982.628.camel@pasglop> <1297552503.14982.637.camel@pasglop> <20110213111450.GD18294@yookeroo> <28596383-B15A-4932-A03C-8C45F5D777D1@suse.de> <1297613854.14982.656.camel@pasglop> In-Reply-To: <1297613854.14982.656.camel@pasglop> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Benjamin Herrenschmidt Cc: Alexander Graf , "qemu-devel@nongnu.org List" , Blue Swirl , Paul Mackerras , anton@samba.org, David Gibson 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. > > > >