From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:55312) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1V1cIQ-0004H8-PY for qemu-devel@nongnu.org; Tue, 23 Jul 2013 09:06:32 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1V1cIL-00004z-Ao for qemu-devel@nongnu.org; Tue, 23 Jul 2013 09:06:30 -0400 Message-ID: <51EE7FBD.1060409@redhat.com> Date: Tue, 23 Jul 2013 15:06:05 +0200 From: Paolo Bonzini MIME-Version: 1.0 References: <1374515411-43818-1-git-send-email-agraf@suse.de> <51EE74D8.5060609@redhat.com> <51EE7864.1030408@redhat.com> In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] [PATCH 0/9] Add platform bus List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Peter Maydell Cc: "qemu-ppc@nongnu.org list:PowerPC" , Alexander Graf , qemu-devel Developers Il 23/07/2013 14:40, Peter Maydell ha scritto: > On 23 July 2013 13:34, Paolo Bonzini wrote: >> Il 23/07/2013 14:22, Peter Maydell ha scritto: >>> On 23 July 2013 13:19, Paolo Bonzini wrote: >>>> Il 22/07/2013 20:21, Peter Maydell ha scritto >>>>> you can't as a user of this sort of hardware >>>>> plug in an extra serial port to a SoC, because there's just nowhere >>>>> to plug it in. So why should it be possible to plug an extra >>>>> serial port into the QEMU model of the SoC? >>>> >>>> And why exactly should QEMU be limited to modeling an existing SoC? >>>> >>>> Perhaps the user is not working with an existing SoC. They are working >>>> with with IP building blocks that they can combine the way they prefer, >>>> and they haven't yet made up their mind on the exact set of devices >>>> they'll have. (because not all the world is a PC, but then not all the >>>> non-PC world is ARM either). >>> >>> This sounds like (a) a good thing (b) something that will >>> turn into an incredible incomprehensible mess if we try >>> to specify it on the command line. Why would we want to do that? >> >> It is an incomprehensible mess on the command line, but it is actually >> quite fine if you use "-readconfig" instead. > > Well, the justification for this whole new bus appears to be > "so you can easily just add a new device on the command line". "-readconfig" is another way to write command line options, e.g. [drive "hd"] file = /home/pbonzini/test.img if = none [device] driver = "virtio-blk" drive = hd or something like that. >>>> Perhaps the user can plug daughterboards that connect to the SoC and add >>>> an extra serial port, visible as yet another MMIO device. >>> >>> Pluggable daughterboards should be implemented by actually >>> defining the bus/socket that exists between the mainboard >>> and the daughterboard, so you could say -device my-daughterboard >>> and have it plug in to the mainboard. >> >> The bus might just be the processor's data bus + the interrupt >> controller's pins, basically the same as sysbus. > > Yes, we should have easy support for defining a pluggable > bus as a collection of pins. And a container memory region too---in the end, this is what Alex's platform bus does. >> In fact, the main thing I dislike about Alex's patch is adding a new bus >> instead of making sysbus devices "just work" as pluggable devices. > > Agreed, more or less. Actually I'd rather sysbus devices > went away -- the requirement for interrupt and GPIO and > memory regions to all be defined as single arrays (so you > have to know what interrupt line 3 happens to be, and > that memory region 1 is the registers, and so on) is > pretty unfriendly. We should be able to define all these > as named connections. Yeah, that's the icing on the cake. :) Paolo