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

[Peter Maydell <peter.maydell@linaro.org>]

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.

thanks
-- PMM