qemu-devel
[Top][All Lists]
Advanced

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

Re: [Qemu-devel] [RFC v2 1/4] hw/arm/virt: Allow multiple agents to modi


From: alvise rigo
Subject: Re: [Qemu-devel] [RFC v2 1/4] hw/arm/virt: Allow multiple agents to modify dt
Date: Tue, 6 Jan 2015 10:29:55 +0100

Hi Eric,

You are right. In fact, I've also spent some time to see if it was
possible to use the code you mentioned.
However, it's not needed anymore: the node generation will happen at
machine init for the reasons discussed in this thread.

Regards,
alvise

On Tue, Jan 6, 2015 at 10:18 AM, Eric Auger <address@hidden> wrote:
> On 01/05/2015 05:14 PM, alvise rigo wrote:
>> Hi,
>>
>> On Mon, Jan 5, 2015 at 4:36 PM, Peter Maydell <address@hidden> wrote:
>>> On 24 November 2014 at 11:47, Claudio Fontana
>>> <address@hidden> wrote:
>>>> On 21.11.2014 19:07, Alvise Rigo wrote:
>>>>> Keep a global list with all the functions that need to modify the device
>>>>> tree.  Using qemu_add_machine_init_done_notifier we register a notifier
>>>>> that executes all the functions on the list and loads the kernel.
>>>>>
>>>>> Signed-off-by: Alvise Rigo <address@hidden>
>>>>
>>>> Peter, could you weigh in about whether this is a good idea or not?
>>>
>>> Sorry, I think I must have missed this series first time around.
>>> I'm not convinced -- I don't see any reason why we should treat
>>> the PCI host controller differently from other devices in the
>>
>> The reason for this is that the PCI host controller needs to generate
>> its device node after all the PCI devices have been added to the bus
>> (also those specified with the -device option).
>> This is required by the interrupt-map node property, that specifies
>> for each PCI device an interrupt map entry. Since we have one device
>> requiring this 'postponed' node generation, this patch allows also
>> other devices to do the same.
>> Recently I was thinking to another approach, which is to have multiple
>> dtb modifiers called by arm_boot_info.modify_dtb(). Is this
>> reasonable?
>>
>>> virt board: just generate an appropriate dtb fragment in virt.c.
>>
>> Of course, the method that generates the device node fragment can be
>> moved to virt.c, but the requirement of postponing its call after the
>> machine has been created still applies.
>
> Hi Alvise, Peter,
>
> Besides the PCI aspects, the dt generation problem that is addressed
> here is identical to the one related to VFIO platform device dt node
> generation that also needs to happen after machine init.
>
> In "machvirt dynamic sysbus device instantiation"
> (https://www.mail-archive.com/address@hidden/msg272506.html),
> arm_load_kernel is proposed to be executed in a machine init done
> notifier and VFIO node creation happens in another machine init done
> notifier registered after this latter.
>
> Best Regards
>
> Eric
>>
>> Thank you for your feedback,
>> alvise
>>
>>>
>>> thanks
>>> -- PMM
>>
>



reply via email to

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