qemu-devel.nongnu.org archive mirror
 help / color / mirror / Atom feed
From: Eric Auger <eric.auger@linaro.org>
To: alvise rigo <a.rigo@virtualopensystems.com>,
	Peter Maydell <peter.maydell@linaro.org>
Cc: Rob Herring <rob.herring@linaro.org>,
	"tech@virtualopensystems.com" <tech@virtualopensystems.com>,
	Claudio Fontana <claudio.fontana@huawei.com>,
	QEMU Developers <qemu-devel@nongnu.org>
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	[thread overview]
Message-ID: <54ABA860.6050908@linaro.org> (raw)
In-Reply-To: <CAH47eN3W4oOR4ma-U1FNY+uAxtC0-gq5a0ykhrmLPfHJ+L9krA@mail.gmail.com>

On 01/05/2015 05:14 PM, alvise rigo wrote:
> Hi,
> 
> On Mon, Jan 5, 2015 at 4:36 PM, Peter Maydell <peter.maydell@linaro.org> wrote:
>> On 24 November 2014 at 11:47, Claudio Fontana
>> <claudio.fontana@huawei.com> 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 <a.rigo@virtualopensystems.com>
>>>
>>> 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/qemu-devel@nongnu.org/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
> 

  parent reply	other threads:[~2015-01-06  9:20 UTC|newest]

Thread overview: 29+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-11-21 18:07 [Qemu-devel] [RFC v2 0/4] Add Generic PCI host device update Alvise Rigo
2014-11-21 18:07 ` [Qemu-devel] [RFC v2 1/4] hw/arm/virt: Allow multiple agents to modify dt Alvise Rigo
2014-11-24 11:47   ` Claudio Fontana
2015-01-05 15:36     ` Peter Maydell
2015-01-05 16:14       ` alvise rigo
2015-01-05 16:41         ` Peter Maydell
2015-01-05 17:35           ` alvise rigo
2015-01-05 18:07             ` Peter Maydell
2015-01-06  9:56               ` alvise rigo
2015-01-06  9:18         ` Eric Auger [this message]
2015-01-06  9:29           ` alvise rigo
2015-01-06  9:51           ` Peter Maydell
2015-01-06 10:05             ` Eric Auger
2014-11-21 18:07 ` [Qemu-devel] [RFC v2 2/4] hw/arm/virt: find_machine_info: handle NULL value Alvise Rigo
2015-01-05 15:36   ` Peter Maydell
2015-01-05 16:31     ` alvise rigo
2015-01-05 16:42       ` Peter Maydell
2014-11-21 18:07 ` [Qemu-devel] [RFC v2 3/4] hw/pci-host: Add a generic PCI host controller for virtual platforms Alvise Rigo
2014-11-24 10:34   ` Claudio Fontana
2014-11-24 14:57     ` alvise rigo
2014-11-25 10:20       ` Claudio Fontana
2015-01-05 17:13   ` Alexander Graf
2015-01-06  8:47     ` alvise rigo
2015-01-06 11:18       ` Alexander Graf
     [not found] ` <1416593261-13751-5-git-send-email-a.rigo@virtualopensystems.com>
2014-11-24 10:38   ` [Qemu-devel] [RFC v2 4/4] hw/arm/virt: Add generic-pci device support Claudio Fontana
2014-11-24 10:47     ` alvise rigo
2014-11-24 15:50 ` [Qemu-devel] [RFC v2 0/4] Add Generic PCI host device update Claudio Fontana
2014-11-25 10:28   ` alvise rigo
2015-01-12 16:26 ` Claudio Fontana

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=54ABA860.6050908@linaro.org \
    --to=eric.auger@linaro.org \
    --cc=a.rigo@virtualopensystems.com \
    --cc=claudio.fontana@huawei.com \
    --cc=peter.maydell@linaro.org \
    --cc=qemu-devel@nongnu.org \
    --cc=rob.herring@linaro.org \
    --cc=tech@virtualopensystems.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).