qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


From: Alexander Graf
Subject: Re: [Qemu-devel] [PATCH 5/6] PPC: e500: Support dynamically spawned sysbus devices
Date: Wed, 02 Jul 2014 22:59:34 +0200
User-agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.6.0


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




reply via email to

[Prev in Thread] Current Thread [Next in Thread]