Re: [Qemu-devel] [PATCH 5/6] PPC: e500: Support dynamically spawned sysbus devices

[Scott Wood]

On Wed, 2014-07-02 at 19:59 +0200, Alexander Graf wrote:
> On 02.07.14 19:52, Scott Wood wrote:
> > On Wed, 2014-07-02 at 19:30 +0200, Alexander Graf wrote:
> >> On 02.07.14 19:26, Scott Wood wrote:
> >>> On Wed, 2014-07-02 at 19:12 +0200, Alexander Graf wrote:
> >>>> On 02.07.14 00:50, Scott Wood wrote:
> >>>>> Plus, let's please not hardcode any more addresses that are going to be
> >>>>> a problem for giving guests a large amount of RAM (yes, CCSRBAR is also
> >>>>> blocking that, but that has a TODO to parameterize).  How about
> >>>>> 0xf00000000ULL?  Unless of course we're emulating an e500v1, which
> >>>>> doesn't support 36-bit physical addressing.  Parameterization would help
> >>>>> there as well.
> >>>> I don't think we have to worry about e500v1. I'll change it :).
> >>> We theoretically support it elsewhere...  Once parameterized, it
> >>> shouldn't be hard to base the address for this, CCSRBAR, and similar
> >>> things on whether MAS7 is supported.
> >> It gets parametrized in the machine file, CPU selection comes after
> >> machine selection. So parameterizing it doesn't really solve it.
> > Why can't e500plat_init() look at args->cpu_model?  Or the
> > parameterization could take two sets of addresses, one for a 32-bit
> > layout and one for a 36-bit layout.  It might make sense to make this a
> > user-settable parameter; some OSes might not be able to handle a 36-bit
> > layout (or might not be as efficient at handling it) even on e500v2.
> > Many of the e500v2 boards can be built for either a 32 or 36 bit address
> > layout in U-Boot.
> >
> >> However, again, I don't think we have to worry about it.
> > It's not a huge worry, but it'd be nice to not break it gratuitously.
> > If we do break it we should explicitly disallow e500v1 with e500plat.
> 
> I'd prefer if we don't overparameterize - it'll just become a headache 
> further down.

"We shouldn't overparameterize" is a tautology.  The question is what
constitutes "over".  I don't think this is excessive.  Again, it's
parameterization that U-Boot already does, even disregarding e500v1, and
QEMU plays the role of U-Boot to a certain degree (even in the new mode
of actually running U-Boot, the address map is fixed).

Perhaps it could be simplified by just saying that, in 36-bit mode, all
physical addresses other than RAM have 0xf prepended.  This is similar
to what U-Boot does.

> Today we don't explicitly disallow anything anywhere - you 
> could theoretically stick a G3 into e500plat. I don't see why we should 
> start with heavy sanity checks now :).

Ugh.

It should at least be documented, since unlike a G3, e500v1 isn't an
unrealistic expectation on a platform called e500plat.

> Plus, the machine works just fine today if you don't pass in -device 
> eTSEC. It's not like we're moving all devices to the new "platform bus".

We have a TODO to move CCSR as well.

-Scott