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: Eric Auger
Subject: Re: [Qemu-devel] dynamic sysbus instantiation and load_dtb implementation
Date: Thu, 13 Nov 2014 14:06:11 +0100
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.2.0

On 11/13/2014 05:02 AM, David Gibson wrote:
> On Fri, Oct 24, 2014 at 02:38:39PM +0200, David Gibson wrote:
>> 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.
> 
> Oh, also, because we potentially have hotplug of VIO devices, it's
> *not* necessarily the same every time.
> 
Thanks for your inputs. I eventually proposed an implementation based on
machine init done notifier, still using rom_add_blob_fixed.

http://lists.nongnu.org/archive/html/qemu-devel/2014-10/msg03812.html

By the way, besides Alex, did anyone have time to review modifs in
hw/arm/boot.c and overall process to enhance the original device tree?
Are those modifications acceptable?

Thank you in advance

Best Regards

Eric




reply via email to

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