From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([208.118.235.92]:44397) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1TBPZu-0002eL-Fw for qemu-devel@nongnu.org; Tue, 11 Sep 2012 08:29:18 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1TBPYd-0003Yv-59 for qemu-devel@nongnu.org; Tue, 11 Sep 2012 08:28:30 -0400 Message-ID: <504F2E1A.8090200@suse.de> Date: Tue, 11 Sep 2012 14:27:06 +0200 From: Alexander Graf MIME-Version: 1.0 References: <1344948607-23291-1-git-send-email-Bharat.Bhushan@freescale.com> <502AFB70.2070101@freescale.com> <6A3DF150A5B70D4F9B66A25E3F7C888D06453361@039-SN2MPN1-022.039d.mgd.msft.net> <50492EA9.3050605@freescale.com> <504A43EC.6030004@freescale.com> <504F2D41.6000404@suse.de> In-Reply-To: <504F2D41.6000404@suse.de> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: quoted-printable Subject: Re: [Qemu-devel] [Qemu-ppc] [PATCH: RFC] Adding BAR0 for e500 PCI controller List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: =?UTF-8?B?QW5kcmVhcyBGw6RyYmVy?= Cc: Scott Wood , Wood Scott-B07421 , "qemu-ppc@nongnu.org" , "qemu-devel@nongnu.org" , Bhushan Bharat-R65777 On 09/11/2012 02:23 PM, Andreas F=C3=A4rber wrote: > Am 07.09.2012 20:58, schrieb Scott Wood: >> On 09/07/2012 03:08 AM, Alexander Graf wrote: >>> On 07.09.2012, at 01:15, Scott Wood wrote: >>> >>>> On 09/03/2012 01:44 AM, Bhushan Bharat-R65777 wrote: >>>>> Can we somehow pass this via qdev/varargs from machine emulation co= de >>>>> (hw/ppc/e500.c) ? >>>> Possibly, though it may not be the best idea to express every single >>>> aspect of intercomponent integration via qdev -- maybe that's best l= eft >>>> for things that are reasonably user-tweakable. If CCSR size is user >>>> tweakable, it would be somewhere other than the PCI controller. >>> It depends. Qdev properties are basically object constructor >>> parameters. So if you were weiting C++ code and would have a >>> constructor that gets the size as argument, it would end up being >>> modeled as qdev property. >>> >>> If however actual functionality differs, thus you would in OO speech >>> create a subclass / child class, then you are better off creating a >>> new device struct. >>> >>> In this case, I'm not sure. They are different devices really, but >>> are close enough that the differences could be expressed through qdev >>> properties. >> I wasn't suggesting that they be different devices. I was suggesting >> that this isn't a property of the PCI controller, but rather of some >> other entity to which the PCI controller connects. So maybe a referen= ce >> to the associated CCSR object would be a qdev parameter, but not the >> size of that CCSR. > For a reference to another object a QOM link<> property would be > preferred over a static qdev property. How does that work? Can we do RPC to other objects to access its CCSR=20 and/or enumerate the CCSR size? Or maybe even receive its memory api bloc= k? Alex