From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:50239) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1WYXT1-0002ie-3m for qemu-devel@nongnu.org; Fri, 11 Apr 2014 05:09:53 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1WYXSt-0002LY-KN for qemu-devel@nongnu.org; Fri, 11 Apr 2014 05:09:47 -0400 Received: from cantor2.suse.de ([195.135.220.15]:56065 helo=mx2.suse.de) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1WYXSt-0002LU-8w for qemu-devel@nongnu.org; Fri, 11 Apr 2014 05:09:39 -0400 Message-ID: <5347B150.2030202@suse.de> Date: Fri, 11 Apr 2014 11:09:36 +0200 From: Alexander Graf MIME-Version: 1.0 References: In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] [PATCH v2 0/4] Allow sysbus devices to be attached via commandline List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Peter Maydell , Alistair Francis Cc: Edgar Iglesias , Peter Crosthwaite , eric.auger@linaro.org, Kim Phillips , QEMU Developers , Markus Armbruster , "Edgar E. Iglesias" , =?UTF-8?B?QW5kcmVhcyBGw6RyYmVy?= On 11.04.14 09:55, Peter Maydell wrote: > On 11 April 2014 07:34, Alistair Francis wrote: >> This patch allows sysbus devices to be attached via >> command line arguments. >> >> This can be used to build an entire machine from the command >> line or to just add devices that aren't in the machine_init >> code. >> >> A peripheral can be added with the following syntax: >> -device cadence_uart,addr=0xE0000000,irq=27 >> >> A CPU can be added with either of the following: >> -device cpu,model=cortex-a9,type=arm-cpu,reset-cbar=0xF8F00000,midr=0x413 FC090 >> -sysbusdev device=cpu,name=microblaze-cp > I don't see how this can possibly be sufficient information > to wire up the CPU properly. How would you specify > where the generic timer outputs go on an A15? > How are you going to handle the private peripheral > mappings? Is the user supposed to provide another > argument for the a9mpcore_priv device? > >> RAM or ROM can be attached with this command: >> -device memory,name=zynq.ext_ram,addr=0x00000000,size=0x8000000 > How would you use this if you needed to manage > multiple separate address spaces? I'm hoping we can > get rid of address_space_memory at some point > in favour of actually properly modelling when different > CPUs or DMA masters have different views of the world, > so I don't want us to tie ourselves into an incorrect > model by command line back-compat problems. > >> Multiple IRQ lines can be used as well as multiple properties: >> -device pl330,addr=0xF8003000,irq=13,irq=14,irq=15,irq=16,irq=17,\ >> irq=40,irq=41,irq=42,irq=43,num_chnls=8,num_periph_req=4,num_events=16 > This doesn't seem to actually specify anywhere how those > IRQ numbers are supposed to be interpreted. You need > to somehow say "connect this IRQ output line up to > device X's GPIO input line Y" (where X will usually but not > necessarily be an interrupt controller). > > Again addr= is assuming a single system wide address > space. > > I also think that "allow machine specification by the > command line" is a terrible goal -- certainly we should allow > users the flexibility to put machines together from individual > devices, but we should do that with a reasonably usable > configuration or scripting language (and then we can use > that internally for our own board models). If you try to > specify things using command line argument syntax as > your primary approach then the result is going to end > up with hard-coded shortcuts (like the address space and > which-interrupt-controller problems I mention above) that > you've ended up with to try to make the command line > vaguely comprehensible. But the real comprehensibility > problem is from trying to do it with a single line of text > with highly constrained syntax conventions. I agree. And both things should be orthogonal goals. I think it makes a lot of sense to work towards converting machine files into say python scripts. But even then users will still want to define additional devices using -device on the command line on top of that base machine file. So we need a solution to link up devices with "facilities provided by the boad" as well - to a certain extent. I'm not sure if it's worth it to worry about the case where a -device provides interfaces that you would need to hook up to from -device again. We already have working interfaces for that really. Alex