qemu-devel.nongnu.org archive mirror
 help / color / mirror / Atom feed
From: Peter Crosthwaite <peter.crosthwaite@xilinx.com>
To: Peter Maydell <peter.maydell@linaro.org>
Cc: qemu list <qemu-devel@nongnu.org>,
	KVM devel mailing list <kvm@vger.kernel.org>,
	Juan Quintela <quintela@redhat.com>
Subject: Re: [Qemu-devel] KVM call agenda for 2014-05-13
Date: Tue, 13 May 2014 09:27:46 +1000	[thread overview]
Message-ID: <CAEgOgz6toLuB59qeCL+6O2Ut48-xP42S4zRMBrJn-dHMi9cuxw@mail.gmail.com> (raw)
In-Reply-To: <CAFEAcA9zMYTd5noO68ofbLe70sMGxcMgAC8jvyw0WFByrkJASA@mail.gmail.com>

On Mon, May 12, 2014 at 9:09 PM, Peter Maydell <peter.maydell@linaro.org> wrote:
> On 12 May 2014 11:30, Peter Crosthwaite <peter.crosthwaite@xilinx.com> wrote:
>> On Mon, May 12, 2014 at 7:44 PM, Peter Maydell <peter.maydell@linaro.org> wrote:
>>> On 12 May 2014 10:10, Juan Quintela <quintela@redhat.com> 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
>

  reply	other threads:[~2014-05-12 23:27 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-05-12  9:10 [Qemu-devel] KVM call agenda for 2014-05-13 Juan Quintela
2014-05-12  9:44 ` Peter Maydell
2014-05-12 10:30   ` Peter Crosthwaite
2014-05-12 11:09     ` Peter Maydell
2014-05-12 23:27       ` Peter Crosthwaite [this message]
2014-05-13 10:44         ` Peter Maydell
2014-05-13 11:07           ` Peter Crosthwaite
2014-05-13 11:31             ` Peter Maydell
2014-05-13 10:21       ` Andreas Färber
2014-05-13 10:33         ` Peter Crosthwaite

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=CAEgOgz6toLuB59qeCL+6O2Ut48-xP42S4zRMBrJn-dHMi9cuxw@mail.gmail.com \
    --to=peter.crosthwaite@xilinx.com \
    --cc=kvm@vger.kernel.org \
    --cc=peter.maydell@linaro.org \
    --cc=qemu-devel@nongnu.org \
    --cc=quintela@redhat.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).