qemu-devel
[Top][All Lists]
Advanced

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

Re: [Qemu-devel] dynamic sysbus instantiation and load_dtb implementatio


From: David Gibson
Subject: Re: [Qemu-devel] dynamic sysbus instantiation and load_dtb implementation
Date: Fri, 24 Oct 2014 14:38:39 +0200
User-agent: Mutt/1.5.23 (2014-03-12)

On Thu, Oct 23, 2014 at 01:26:08PM +0200, Alexander Graf wrote:
> 
> 
> On 23.10.14 13:24, Peter Maydell wrote:
> > On 23 October 2014 12:23, Alexander Graf <address@hidden> wrote:
> >> On 23.10.14 12:19, Ard Biesheuvel wrote:
> >>> The reason for this change was that, before, the DTB would only be
> >>> generated once, and after a reset, the machine would go through the
> >>> kernel boot protocol as before but the DTB pointer would point to
> >>> garbage. Any idea how ppc deals with this? Do they recreate the device
> >>> tree after each reset?
> >>
> >> Yes, we regenerate the device tree on each reset.
> > 
> > Any particular reason? Surely it's always the same...
> 
> We have the code in place anyway, it's not a performance critical code
> path and putting it into a rom would be a waste of RAM, as it'd keep yet
> another copy of something we can easily regenerate.
> 
> It's a matter of personal preference I guess.

The "pseries" machine actually uses an odd hybrid.  We create a
"template" device tree with the common portions during early init.
That's stored permanently, but is not guest visible.

At reset time we augment the template with information which could
very from one boot to another, then copy it into RAM for the SLOF
firmware to read.

It's not particularly efficient, but really, who cares.  It's once per
resent, and we're generally talking at most a few dozen kiB of device
tree.

-- 
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: pgpjx2IK4CXo5.pgp
Description: PGP signature


reply via email to

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