qemu-devel.nongnu.org archive mirror
 help / color / mirror / Atom feed
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
> 

      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).