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: Eric Auger
Subject: Re: [Qemu-devel] [RFC v2 1/4] hw/arm/virt: Allow multiple agents to modify dt
Date: Tue, 06 Jan 2015 10:18:24 +0100
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.2.0

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]