From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:45339) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1X0UVl-0002bq-Lo for qemu-devel@nongnu.org; Fri, 27 Jun 2014 07:40:15 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1X0UVf-000416-JG for qemu-devel@nongnu.org; Fri, 27 Jun 2014 07:40:09 -0400 Message-ID: <53AD5810.7030505@suse.de> Date: Fri, 27 Jun 2014 13:40:00 +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: <53AD47B6.5010007@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 , Paolo Bonzini Cc: qemu-ppc Mailing List , "qemu-devel@nongnu.org Developers" , Eric Auger On 27.06.14 12:30, 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 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= map >>>> a device's memory regions into any other random memory region. All o= f >>>> 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 t= o >>> avoid having to dup all the sysbus device models for both regular >>> sysbus and platform bus. I think your functionality should be added a= s >>> 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 devic= es >> 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 w= e > 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. > > 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. So my goal is to make life easy for users, not to fulfill some wet=20 Anthony dreams :). And as a user, I want to be able to say -device foo=20 and have that device created, like I do with PCI devices today. There are 2 approaches to this that I can see: 1) A new special type of bus that allows for dynamic allocation and=20 that knows a flat numbering scheme 2) Individual devices that get attached to whatever the machine file=20 thinks makes it happy (basically emulating the above bus, but with more=20 flexibility) I implemented option 1 with the "Platform bus". It's basically an=20 abstraction of the Sys/AXI/AMBA idea but only with a single bus=20 implementation, as everything else would just be ridiculously redundant=20 (and if necessary could be implemented as a subclass on top of the=20 bridge device). People didn't like it. I implemented option 2 with the Platform devices - this patch set.=20 People didn't like it because it duplicates SysBus devices - and it does. I'm implementing 2 as an add-on of SysBusDevice now which to me really=20 isn't too much different from a dangling QOM device. Linking devices by force (set IRQ0 to MPIC IRQ 32, map region0 to=20 physical address space offset 0x12300) is a nice thing to have for=20 people who know what they're doing. That matches probably about 0.00001%=20 of our user base - I personally am not included there. We *have* to have=20 a mechanism to make device creation easy for users if we want to have any= . Alex