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
>
next prev parent 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).