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

[Alistair Francis]

On Fri, Apr 11, 2014 at 7:13 PM, Peter Crosthwaite
<address@hidden> wrote:
> On Fri, Apr 11, 2014 at 5:55 PM, Peter Maydell <address@hidden> wrote:
>> On 11 April 2014 07:34, Alistair Francis <address@hidden> 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?
>>
At the moment it doesn't allow generic timer outputs or any complex connections
like that, that might be possible to implement (see below). Sorry, I
should have specified that
the a9mpcore_priv needs to be added by a separate -device argument

>>> 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.
>>
See below
>
> And sys-busses should be referencable and instantiable objects in
> their own right. Can we create a sysbus with:
>
> -device sysbus,name=blah
>
> This should all work somehow with Edgars recent per-master-address
> series. Masters then also need to specify their attachments in a data
> driven way.
>
> -device arm-cpu,master-bus=blah
>
>>> 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).
>>
See below
>
> This is probably blocked by consolidation of GPIOs and IRQs.
> Unforuntately, Sysbus keeps it's own data structure and APIs for IRQs
> quite separate from TYPE_DEVICEs GPIO API. I also think purely
> numbered and unnamed GPIOs need to be phased-out as its a blocker on
> quite a few features.
>
> So anyways heres my proposal around IRQs/GPIOs. I have a series on
> list that adds the capability to name GPIOs. We  can use it to
> consolidate sysbus::IRQ and device::GPIO by naming all sysbus IRQ
> lists (lets just call them "irqs") and moving them into the regular
> device->gpio structure. Existing sysbus_foo_irq APIs just back onto
> this change so there is no tree-wide change needed. Then instead of
> command line IRQ support we add command line GPIO support and the one
> soln. just works for all forms of wires.
>
I think this is a good idea.

>> 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.

Overall I agree this implementation makes a lot of assumptions to simplify
the complexity of machine model generation. I still think it should be possible
for a user to at least add sysbus devices to QEMU via the command line. The
CPU, memory and interrupt controller could be a bit much and too complex to
attach via command line, but users should be able to attach most other
QOM devices.

Even just allowing relatively simple devices to be added via the
command line will eventually
make it easier to implement a scripting language to generate entire machines.

The command line arguments could be extended to allow 'masters', or
something similar
which specify what to connect to. For example device's X interrupt
lines or different address
spaces.

>
> I feel its something of the opposite here. The ultimate goal of an
> entire machine on the command line brings to light all these issues
> around generalization that are ultimately applicable to machine
> extension. Whether not you actually use -M none { -device } is beside
> the point. If you assume you have nothing, and aim to be able to do
> anything you have less worries about future incapability.
>
> But the real comprehensibility
>> problem is from trying to do it with a single line of text
>> with highly constrained syntax conventions.
>>
One last point, although it is highly constrained, it still allows
complete generation
of relatively simple machines. Something which I think will benefit
end users, and if they
want to do anything more complex they can write C code (or a scripting language)
and implement it that way.

Thanks,
Alistair
>
> And this email thread has quite nicely listed out those constraints. I
> think we should get rid of them and continue evolving this idea until
> it works.
>
> Regards,
> Peter
>
>> thanks
>> -- PMM
>>
>