From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:41410) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1X0UH4-0000yL-MG for qemu-devel@nongnu.org; Fri, 27 Jun 2014 07:25:04 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1X0UGx-0006uI-Ra for qemu-devel@nongnu.org; Fri, 27 Jun 2014 07:24:57 -0400 Message-ID: <53AD5480.8030807@suse.de> Date: Fri, 27 Jun 2014 13:24:48 +0200 From: Alexander Graf MIME-Version: 1.0 References: <1401884936-12907-1-git-send-email-agraf@suse.de> <53AC0B94.3060400@suse.de> <53AD47B6.5010007@suse.de> <53AD52CE.8040509@suse.de> In-Reply-To: <53AD52CE.8040509@suse.de> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: quoted-printable Subject: Re: [Qemu-devel] [PATCH 0/5] Platform device support List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: =?UTF-8?B?QW5kcmVhcyBGw6RyYmVy?= , Peter Crosthwaite Cc: Paolo Bonzini , qemu-ppc Mailing List , "qemu-devel@nongnu.org Developers" , Eric Auger On 27.06.14 13:17, Andreas F=C3=A4rber wrote: > Am 27.06.2014 12:54, schrieb Peter Crosthwaite: >> On Fri, Jun 27, 2014 at 8:30 PM, Andreas F=C3=A4rber wrote: >>> Am 26.06.2014 14:01, schrieb Alexander Graf: >>>> On 20.06.14 08:43, Peter Crosthwaite wrote: >>>>> On Wed, Jun 4, 2014 at 10:28 PM, Alexander Graf wro= te: >>>>>> Platforms without ISA and/or PCI have had a seriously hard time in >>>>>> the dynamic >>>>>> device creation world of QEMU. Devices on these were modeled as >>>>>> SysBus devices >>>>>> which can only be instantiated in machine files, not through -devi= ce. >>>>>> >>>>>> Why is that so? >>>>>> >>>>>> Well, SysBus is trying to be incredibly generic. It allows you to >>>>>> plug any >>>>>> interrupt sender into any other interrupt receiver. It allows you = to map >>>>>> a device's memory regions into any other random memory region. All= of >>>>>> that >>>>>> only works from C code or via really complicated command line >>>>>> arguments under >>>>>> discussion upstream right now. >>>>>> >>>>> What you are doing seem to me to be an extension of SysBus - you ar= e >>>>> defining the same interfaces as sysbus but also adding some machine >>>>> specifics wiring info. I think it's a candidate for QOM inheritance= to >>>>> avoid having to dup all the sysbus device models for both regular >>>>> sysbus and platform bus. I think your functionality should be added= as >>>>> one of >>>>> >>>>> 1: and interface that can be added to sysbus devices >>>>> 2: a new abstraction that inherits from SYS_BUS_DEVICE >>>>> 3: just new features to the sysbus core. >>>>> >>>>> Then both of us are using the same suite of device models and the >>>>> differences between our approaches are limited to machine level >>>>> instantiation method. My gut says #2 is the cleanest. >>>> The more I think about it the more I believe #3 would be the cleanes= t. >>>> The only thing my platform devices do in addition to sysbus devices = is >>>> that it exposes qdev properties to give mapping code hints where a >>>> device wants to be mapped. >>>> >>>> If we just add qdev properties for all the possible hints in generic >>>> sysbus core code, we should be able to automatically convert all dev= ices >>>> into dynamically allocatable devices. Whether they actually do get >>>> mapped and the generation of device tree chunks still stays in the t= he >>>> machine file's court. >>> As discussed offline with Alex, one issue I see is that this would be >>> encouraging people to add more devices to an artificial global bus in >>> /machine/unassigned that we've been trying to obsolete, rather than >>> sitting down and please creating an e500 SoC object as a start. Maybe= we >>> should start generating a list of shame for 2.1. ;) >>> Instantiating a new [Sys/AXI/AMBA/...]Bus inside that SoC object woul= d >>> make me much happier than using SysBus as is. >>> >> Do you mean &address_space_memory (as used by sysbus_mmio_map)? > No, I mean the QOM composition model. When we think of using -device, > then they will go to /machine/peripheral/ or > /machine/peripheral-anon/device[n]; in your case that means that you ge= t > a flat list of devices rather than a structure matching your device > tree. And like I said above, in both your and Alex' case SysBus is > something that has no real place in the composition tree unless we go > from that single unholy qdev-required bus to buses as they exist in the > hardware, like Anthony suggested long time ago. Alex' problem with that > is that he doesn't want to implement the same UART logic for 50 > different-but-same buses, so some form of reuse or inheritance would be > needed. > > Disclaimer: I have not yet reviewed this series, I was commenting on > abstract ideas that Alex requested feedback for. I think we can all agree that the sysbus bus is not a bus per se. So=20 conceptually, what's the difference between a device attached to a=20 non-bus and a device not attached to a bus at all? And why can't we=20 convert sysbus to not be a bus anymore? Alex