[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
>