From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:51495) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1WYXau-0003Sg-0N for qemu-devel@nongnu.org; Fri, 11 Apr 2014 05:18:00 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1WYXal-000546-0E for qemu-devel@nongnu.org; Fri, 11 Apr 2014 05:17:55 -0400 Received: from cantor2.suse.de ([195.135.220.15]:56228 helo=mx2.suse.de) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1WYXak-000541-Kf for qemu-devel@nongnu.org; Fri, 11 Apr 2014 05:17:46 -0400 Message-ID: <5347B337.5010109@suse.de> Date: Fri, 11 Apr 2014 11:17:43 +0200 From: Alexander Graf MIME-Version: 1.0 References: <87mwg6ejn8.fsf@elfo.mitica> <45D2CAA0-636E-4335-A980-EC8B23E4A51D@suse.de> <87ppkoqpf7.fsf@blackfin.pond.sub.org> In-Reply-To: <87ppkoqpf7.fsf@blackfin.pond.sub.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] KVM call agenfda for 2014-04-01 List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Markus Armbruster Cc: Peter Maydell , Peter Crosthwaite , KVM devel mailing list , Juan Quintela , Stuart Yoder , qemu list , Anthony Liguori , Alistair Francis , =?ISO-8859-1?Q?Andreas_F=E4rber?= , Christoffer Dall On 11.04.14 09:46, Markus Armbruster wrote: > [Cc: Andreas, Anthony] > > Alexander Graf writes: > >> On 10.04.2014, at 17:52, Peter Maydell wrote: >> >>> On 10 April 2014 16:49, Alexander Graf wrote: >>>> For the next call, I would propose to revive the "platform bus" >>>> (aka: how to create non-PCI devices with -device) discussions > Rather: devices that connect to more than just a bus. > > Since pseudo-bus sysbus provides exactly no connections, sysbus devices > generally connect to more. > > Currently, the only way to make such additional connections is > special-purpose code. -device's connection engine can only connect to a > bus. > >>>> to make sure we're all on the same page. >>> I rather suspect we are not :-) Do you have a link to >>> the current proposals for prior reading? >> The only thing I could find is the old thread about my platform bus >> approach (which Anthony disliked): >> >> https://lists.gnu.org/archive/html/qemu-devel/2013-07/msg03614.html >> >> So from what I remember the plan moving forward was to have a special >> device type similar to my platform bus devices that you can just >> create using -device, no bus involved. The machine file would then >> loop through them, interpret the "I sit at address x" and "I want >> interrupt number y" fields to link them to whatever the machine model >> thinks is a good fit. >> >> The same way the machine model today has to have knowledge on each >> device tree node type it generates, it would do the same for these >> devices. So the machine has to have awareness of all the "funky >> special options" a device tree node receives - the same as for any >> other device. Just that in this case it wouldn't be able to hardcode >> them, but have to generate them on the fly when it sees a device in >> the object tree. > The following is just my understanding of where we're trying to go. The > people active in this field (Andreas?) should correct misunderstandings. > > Our overall goal is building machines from components by *data* rather > than code. Once it's data, it can be made run-time configuration. I've had plenty of discussions on this with Anthony over the years (first time this came up was about 2 or 3 years ago) on this. Eventually his conclusion was that it's not desirable to build the machine from data. Instead it should get built from a script. The nice thing about a script is that it's also run-time, but not as restricted and as much special-cased as a mere description. Unfortunately I don't know all of the rationale that went into the conclusion :). > The configuration describes how components are to be connected, and > generic connection code makes the connections guided by the > configuration. > > The current generic connection code can only connect a device to a > single bus. > > If you don't specify the bus, it picks one. Which one it picks is > effectively ABI. > > Picking a bus is a special case of "pick a connection if user didn't > specify one". The current bus-picker doesn't depend on the machine > type, but that's not going to hold in general. > > I like to think of the "pick connections the user didn't specify" engine > as conceptually separate from the "make connections driven by > configuration" engine. The actual code isn't so separate, but that's > implementation. > > How does your "platform device" proposal (for lack of a better > expression) fit into this general framework of ideas? Any leaf devices that are not hooked up to anything get connected by machine specific code :). So the "pick connections the user didn't specify" logic would be machine specific. Alex