From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:35842) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1X0Tnf-00013z-66 for qemu-devel@nongnu.org; Fri, 27 Jun 2014 06:54:40 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1X0TnW-0006FH-VK for qemu-devel@nongnu.org; Fri, 27 Jun 2014 06:54:35 -0400 Received: from mail-ve0-f173.google.com ([209.85.128.173]:49646) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1X0TnW-0006F8-QE for qemu-devel@nongnu.org; Fri, 27 Jun 2014 06:54:26 -0400 Received: by mail-ve0-f173.google.com with SMTP id db11so5131715veb.32 for ; Fri, 27 Jun 2014 03:54:26 -0700 (PDT) MIME-Version: 1.0 Sender: peter.crosthwaite@petalogix.com In-Reply-To: <53AD47B6.5010007@suse.de> References: <1401884936-12907-1-git-send-email-agraf@suse.de> <53AC0B94.3060400@suse.de> <53AD47B6.5010007@suse.de> Date: Fri, 27 Jun 2014 20:54:25 +1000 Message-ID: From: Peter Crosthwaite Content-Type: text/plain; charset=UTF-8 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?Q?Andreas_F=C3=A4rber?= Cc: Paolo Bonzini , Eric Auger , qemu-ppc Mailing List , Alexander Graf , "qemu-devel@nongnu.org Developers" On Fri, Jun 27, 2014 at 8:30 PM, Andreas F=C3=A4rber wro= te: > 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 wrote: >>>> 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 -device. >>>> >>>> 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 m= ap >>>> 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 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 devices >> into dynamically allocatable devices. Whether they actually do get >> mapped and the generation of device tree chunks still stays in the the >> 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?). Regards, Peter > The pure QOM approach would be link<> properties instead of a bus, but > then the machine needs to know how many "slots" there shall be in > advance. Note that the "docking procedure" is always initiated from the > realizing device, whether bus or no bus. > > Regards, > Andreas > > -- > SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 N=C3=BCrnberg, Germany > GF: Jeff Hawn, Jennifer Guild, Felix Imend=C3=B6rffer; HRB 16746 AG N=C3= =BCrnberg >