Re: [Qemu-ppc] [Qemu-devel] [PATCH: RFC] Adding BAR0 for e500 PCI controller

[Alexander Graf]

On 09/11/2012 02:23 PM, Andreas Färber 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 <address@hidden> wrote:
> > >
> > > > On 09/03/2012 01:44 AM, Bhushan Bharat-R65777 wrote:
> > > > > Can we somehow pass this via qdev/varargs from machine emulation code
> > > > > (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 left
> > > > 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 reference
> > 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 
and/or enumerate the CCSR size? Or maybe even receive its memory api block?


Alex