Re: [Qemu-devel] [PATCH v2 0/4] Allow sysbus devices to be attached via commandline

[Alexander Graf <agraf@suse.de>]

On 11.04.14 09:55, Peter Maydell wrote:
> On 11 April 2014 07:34, Alistair Francis <alistair.francis@xilinx.com> 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