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

[Alexander Graf <agraf@suse.de>]

On 02.07.14 21:34, Scott Wood wrote:
> 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.

I think we should just have another machine type for that case - one 
that is 32bit and one that is 36bit compatible.

>
>> 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.

Yes, that's certainly a good goal to have :).


Alex