Re: [Qemu-devel] KVM call agenda for 2014-05-13

[Peter Crosthwaite]

On Mon, May 12, 2014 at 9:09 PM, Peter Maydell <address@hidden> wrote:
> On 12 May 2014 11:30, Peter Crosthwaite <address@hidden> wrote:
>> On Mon, May 12, 2014 at 7:44 PM, Peter Maydell <address@hidden> wrote:
>>> On 12 May 2014 10:10, Juan Quintela <address@hidden> wrote:
>>>> Please, send any topic that you are interested in covering.
>>>>
>>>> - QOMifying both Memory regions and GPIOs and attaching them via QOM
>>>>   links (Peter Crosthwaite)
>>>
>>> Is there some further useful material on-list on this subject, or
>>> are we just going to have a rerun of the discussions on the
>>> last two calls?
>
>> I have any ugly work-in-progress series. TBH I was going to wait for
>> discussion outcomes. Want me to RFC it?
>
> I don't think you necessarily need to post code, but maybe a writeup
> of current status/options would be useful to try to make the on-call
> discussion productive?
>

Ok so here's my plan:

QOMify address spaces. So they can be instantiated, reffed etc.
completely aside from the hotplug discussion this greatly helps
connecting bus master devices using proper QOM links. E.G. using
machine-set link properties rather &address_space_memory everywhere.

QOMify Memory regions. So they are added as child objects to devices.
Devices can do this explicitly in instance_init, or sysbus can handle
it - sysbus_init_mmio parents the memory region to the device to
transparently convert all existing devs to compliance.

The address and container (the memory region containing this one as a
subregion) of memory regions are QOM properties, of type integer and
link resp. Setting the properties does the
memory_region_add_subregion().

The root address space is parented the machine in exec.c. This give
the address space a canonical path. Its root memory region is a child
of it, so it also is referencable by canon path.

Sysbus IRQ are abandoned completely and re-implemented as named GPIOs.
The sysbus irq API remains and makes this transition
behind-the-scenes.

GPIOs are QOMified. qemu_allocate_irqs does the object_new() etc. IRQ
inputs are then added as child objects of the instantiating device.
Handled by qemu_init_gpio_in_named(). gpio_outs are setup as links.
qdev_connect_gpio_out does the linkage.

QOM is patched to allow setting of a device's child's properties from
a ref to the parent. Best illustrated by example (see below).

Anyways without a single patch to the command line interface, HMP,
QMP, or implementing any machine specific hotplug or adding any new
special busses, this works:

-device xlnx.xps-timer,\
sysbus-mr-0.container=/machine/sysmem/root-mr,\
sysbus-mr-0.addr=0x83c00000,\
sysbus-irq-0=/machine/intc/unnamed-gpio-0

All the other ways to create devices should just work, this is not a
command line specific feature.

Note, I edited my machine model to sanitize the canonical path of the
interrupt controller:

--- a/hw/microblaze/petalogix_s3adsp1800_mmu.c
+++ b/hw/microblaze/petalogix_s3adsp1800_mmu.c
@@ -97,6 +97,8 @@ petalogix_s3adsp1800_init(QEMUMachineInitArgs *args)
                           1, 0x89, 0x18, 0x0000, 0x0, 1);

     dev = qdev_create(NULL, "xlnx.xps-intc");
+    object_property_add_child(qdev_get_machine(), "intc", OBJECT(dev),
+                              &error_abort);


But you could have done the whole /machine/unattached/... ugliness
too. If you name the irq inputs in the intc with my named GPIO series
stuff the unnamed-gpio ugliness goes away too. If you throw away
sysbus and do the memory-regions and IRQs naming the child objects
properly the ugly sysbus names can de dispensed with too. But thats a
big tree-wide to name everything properly.

Regards,
Peter

> thanks
> -- PMM
>