From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from [140.186.70.92] (port=55777 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1PodeT-0003Z1-1G for qemu-devel@nongnu.org; Sun, 13 Feb 2011 10:14:17 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1PodeR-00032J-V0 for qemu-devel@nongnu.org; Sun, 13 Feb 2011 10:14:16 -0500 Received: from mail-yi0-f45.google.com ([209.85.218.45]:64066) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1PodeR-000323-Qb for qemu-devel@nongnu.org; Sun, 13 Feb 2011 10:14:15 -0500 Received: by yie21 with SMTP id 21so1899661yie.4 for ; Sun, 13 Feb 2011 07:14:15 -0800 (PST) Message-ID: <4D57F542.50207@codemonkey.ws> Date: Sun, 13 Feb 2011 09:14:10 -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> In-Reply-To: <28596383-B15A-4932-A03C-8C45F5D777D1@suse.de> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Alexander Graf Cc: Blue Swirl , Paul Mackerras , "qemu-devel@nongnu.org List" , anton@samba.org, David Gibson On 02/13/2011 06:40 AM, Alexander Graf wrote: > >> Ah, yeah. I'm still not sure what to do about it. I was going to >> fold the dynamic hcall registration into the patch set before >> upstreaming. But then something paulus said made me rethink whether >> the dynamic registration was a good idea. Still need to sort this out >> before the series is really ready. >> > 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. > Ignore the qdev bit for a moment. Hypercalls could be plausibly implemented as another I/O space from a processor so the thing to model off of would be PIO dispatch (cpu_outb and friends). From a qdev perspective, having a VIO bus makes sense. The details of which I/O spaces are uses are not as important from a device tree perspective. Regards, Anthony Liguori > Alex > > >