From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:54973) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1X2Rd4-00018x-Vb for qemu-devel@nongnu.org; Wed, 02 Jul 2014 16:59:54 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1X2Rcx-0005Bx-G9 for qemu-devel@nongnu.org; Wed, 02 Jul 2014 16:59:46 -0400 Message-ID: <53B472B6.4030503@suse.de> Date: Wed, 02 Jul 2014 22:59:34 +0200 From: Alexander Graf MIME-Version: 1.0 References: <1404251378-5242-1-git-send-email-agraf@suse.de> <1404251378-5242-6-git-send-email-agraf@suse.de> <1404255054.21434.7.camel@snotra.buserror.net> <53B43D6C.90903@suse.de> <1404321984.21434.24.camel@snotra.buserror.net> <53B44198.5050307@suse.de> <1404323576.21434.41.camel@snotra.buserror.net> <53B4487B.2070109@suse.de> <1404329692.21434.52.camel@snotra.buserror.net> In-Reply-To: <1404329692.21434.52.camel@snotra.buserror.net> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] [PATCH 5/6] PPC: e500: Support dynamically spawned sysbus devices List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Scott Wood Cc: peter.maydell@linaro.org, peter.crosthwaite@xilinx.com, eric.auger@linaro.org, qemu-devel@nongnu.org, qemu-ppc@nongnu.org, sean.stalley@intel.com, pbonzini@redhat.com, afaerber@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