From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:45611) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1X0UXG-0004DN-TR for qemu-devel@nongnu.org; Fri, 27 Jun 2014 07:41:50 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1X0UXA-0004UV-PS for qemu-devel@nongnu.org; Fri, 27 Jun 2014 07:41:42 -0400 Message-ID: <53AD586F.9010607@suse.de> Date: Fri, 27 Jun 2014 13:41:35 +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> In-Reply-To: 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: Peter Crosthwaite , =?UTF-8?B?QW5kcmVhcw==?= =?UTF-8?B?IEbDpHJiZXI=?= Cc: Paolo Bonzini , qemu-ppc Mailing List , "qemu-devel@nongnu.org Developers" , Eric Auger On 27.06.14 12:54, Peter Crosthwaite wrote: > 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 wrot= e: >>>>> 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 -devic= e. >>>>> >>>>> 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 t= o 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 are >>>> 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 cleanest= . >>> The only thing my platform devices do in addition to sysbus devices i= s >>> 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 devi= ces >>> into dynamically allocatable devices. Whether they actually do get >>> mapped and the generation of device tree chunks still stays in the th= e >>> 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 would >> make me much happier than using SysBus as is. >> > Do you mean &address_space_memory (as used by sysbus_mmio_map)? We all > hate that global singleton, but can we decouple it from sysbus which > is not the root cause of that problem? sysbus_mmio_map usages just > need to be replaced with sysbus_mmio_get_region and you can create > whatever heirachy you want using unchanged sysbus devices. > > Even if we phase out the global singleton and the SysBus "bus", the > sysbus "device" abstraction is still sound and should be usable > busless. Then theres no need a for a tree-wide to implement Alex's > feature for all devs (assuming his plugger can be made to work > hintless?). The plugger works just fine when you don't give hints - then it's up to=20 dynamic allocation (same as PCI). Yes I fully agree with you here. Alex