qemu-ppc
[Top][All Lists]
Advanced

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

Re: [Qemu-ppc] [SLOF] [PATCH v4] board-qemu: add private hcall to inform


From: David Gibson
Subject: Re: [Qemu-ppc] [SLOF] [PATCH v4] board-qemu: add private hcall to inform host on "phandle" update
Date: Sat, 30 Sep 2017 13:18:41 +1000
User-agent: Mutt/1.9.0 (2017-09-02)

On Fri, Sep 29, 2017 at 06:04:56PM -0500, Segher Boessenkool wrote:
> On Fri, Sep 29, 2017 at 08:08:56PM +0200, Thomas Huth wrote:
> > On 29.09.2017 10:18, Segher Boessenkool wrote:
> > > I'm a bit worried about the phandles FDT requires, which are a different
> > > size than what OF uses (OF uses cell size, which is 64 bit on 64-bit OF;
> > > the device tree specification uses 32 bit always).
> > > 
> > > Now usually everything lives low in memory, so the top 32 bits will all
> > > be zeroes, but do we guarantee that anywhere (and do we want to restrict
> > > to that!)
> > 
> > Currently QEMU puts the RTAS binary and the FDT just at the end of the
> > RMA or below 2G, whatever is lower (look for RTAS_MAX_ADDR in
> > hw/ppc/spapr.c). SLOF then puts itself right in front of the FDT from
> > QEMU (see romfs_base in board-qemu/llfw/stage2.c in the SLOF sources),
> > so everything related to SLOF always lives in the first 2G of RAM. Thus
> > we should be fine here.
> 
> Yep, and SLOF encodes (at least some) ihandles as just 32 bit (and actually
> reads them from the device tree again constantly, bad plan -- see other
> thread).
> 
> I guess we can live with the restriction, certainly if we only do this
> create-FDT-from-the-real-device-tree thing when running under QEMU.

64-bit phandles would break much, much more than just this proposal.

-- 
David Gibson                    | I'll have my music baroque, and my code
david AT gibson.dropbear.id.au  | minimalist, thank you.  NOT _the_ _other_
                                | _way_ _around_!
http://www.ozlabs.org/~dgibson

Attachment: signature.asc
Description: PGP signature


reply via email to

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