From: Eric Auger <eric.auger@linaro.org>
To: qemu list <qemu-devel@nongnu.org>
Cc: Peter Maydell <peter.maydell@linaro.org>,
Rob Herring <rob.herring@linaro.org>,
Alvise Rigo <a.rigo@virtualopensystems.com>,
Stuart Yoder <stuart.yoder@freescale.com>,
"Bharat.Bhushan@freescale.com" <Bharat.Bhushan@freescale.com>,
Alexander Graf <agraf@suse.de>,
Christoffer Dall <christoffer.dall@linaro.org>
Subject: Re: [Qemu-devel] Dynamic QEMU platform device instantiation in machine files: phone call on Wed July 30
Date: Wed, 30 Jul 2014 18:39:33 +0200 [thread overview]
Message-ID: <53D91FC5.8050305@linaro.org> (raw)
In-Reply-To: <53D675D3.6080508@linaro.org>
Dear all,
Please find my notes for today's call.
Feel free to correct and add any comments.
Best Regards
Eric
Agenda:
discuss dynamic instantiation of QEMU platform devices and
especially discuss where we put the code associated to
their dt node generation and also qom binding.
Attendees:
- Eric Auger
- Bharat Bhusan
- Alexander Graf
- Rob Herring
- Peter Maydell
- Alvise Rigo
- Stuart Yoder
Content:
- Consensus on the fact the QEMU device is the wrong place to
put that code. Rationale is there are too many platforms to
support and device do not have sufficient knowledge to elaborate
the dt node. Example is support of dma handles, clock handles/names,
... which are rather known at board level.
- Alex thinks the device tree generation will be quite difficult to
share between different archi because of the device tree
specificities. For a same archi it looks feasible to share
between different boards.
- devices likely to be dynamically instantiable look to be among:
PPC: ethernet ctler, serial ports, vfio device, sata ctrler
ARM: serial ports, vfio device, virtio-mmio
It is a restricted list and definitively the purpose is not to have
all platform devices dynamically instantiable.
- According to Alex, it is sensible to dynamically instantiate
serial ports as well for ARM because libvirt needs that feature
- for PPC it should be < 5 device types, no overlap with ARM is
foreseen.
- Alex encourages to target to have qom mapping generic, shared between
PPC and ARM and keep dt generation in machile file. When there
are too many things added in the machine file, start moving that
code in a separate file.
- about the location of the platform bus, one idea would be to
use unused virtio transport slots. The idea would be not to
shrink the PCI window or change any RAM region. I did not yet fully
understand how much virtio transports are reasonably needed.
- next: next patches attempting to achieve
x shared plat device QOM mapping (PPC/ARM) used by e500 and virt
x dt generation back in virt.c, candidates are calxeda xgmac, PL330,
virtio-mmio as a poc
On 07/28/2014 06:09 PM, Eric Auger wrote:
> Dear all,
>
> For your information, a phone call will be held this week on Wed July
> 30, 17h-18h CET to address the topic of dynamic instantiation of QEMU
> platform devices in machine files (using the -device qemu option).
>
> Related threads are:
> http://lists.gnu.org/archive/html/qemu-ppc/2014-07/msg00047.html
> http://lists.gnu.org/archive/html/qemu-devel/2014-07/msg01019.html
>
> The objective of the meeting is to discuss (and hopefully reach a
> consensus) on where we can put the code associated to platform device dt
> node generation and also qom binding stuff.
>
> In case you are interested in this discussion, please contact me and I
> will send you the phone call details.
>
> Best Regards
>
> Eric
>
prev parent reply other threads:[~2014-07-30 16:40 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-07-28 16:09 [Qemu-devel] Dynamic QEMU platform device instantiation in machine files: phone call on Wed July 30 Eric Auger
2014-07-29 6:24 ` Markus Armbruster
2014-07-29 7:47 ` Eric Auger
2014-07-29 9:07 ` Markus Armbruster
2014-07-29 9:42 ` Eric Auger
2014-07-30 16:39 ` Eric Auger [this message]
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=53D91FC5.8050305@linaro.org \
--to=eric.auger@linaro.org \
--cc=Bharat.Bhushan@freescale.com \
--cc=a.rigo@virtualopensystems.com \
--cc=agraf@suse.de \
--cc=christoffer.dall@linaro.org \
--cc=peter.maydell@linaro.org \
--cc=qemu-devel@nongnu.org \
--cc=rob.herring@linaro.org \
--cc=stuart.yoder@freescale.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).