qemu-devel
[Top][All Lists]
Advanced

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

Re: [Qemu-devel] Dynamic QEMU platform device instantiation in machine f


From: Eric Auger
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
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.2.0

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
> 




reply via email to

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