From: "Andreas Färber" <afaerber@suse.de>
To: Peter Crosthwaite <peter.crosthwaite@xilinx.com>,
"qemu-devel@nongnu.org Developers" <qemu-devel@nongnu.org>
Cc: Edgar Iglesias <edgar.iglesias@xilinx.com>,
Paolo Bonzini <pbonzini@redhat.com>,
Peter Maydell <peter.maydell@linaro.org>
Subject: Re: [Qemu-devel] [RFC v1 11/25] irq: Slim conversion of qemu_irq to QOM [WIP]
Date: Mon, 19 May 2014 11:13:43 +0200 [thread overview]
Message-ID: <5379CB47.5040703@suse.de> (raw)
In-Reply-To: <CAEgOgz6qrvoU0SXRK59EgjNOusMr4xaEGe2BkWw0AY4Y7LGi8Q@mail.gmail.com>
Am 19.05.2014 03:52, schrieb Peter Crosthwaite:
> On Fri, May 16, 2014 at 11:56 AM, Peter Crosthwaite
> <peter.crosthwaite@xilinx.com> wrote:
>> From: Andreas Färber <afaerber@suse.de>
>>
>> As a prequel to any big Pin refactoring plans, do an in-place conversion
>> of qemu_irq to an Object, so that we can reference it in link<> properties.
>>
>> Signed-off-by: Andreas Färber <afaerber@suse.de>
(Note that you forgot to sign off here.)
>> ---
>>
>> hw/core/irq.c | 44 +++++++++++++++++++++++++++++++++++++++++---
>> include/hw/irq.h | 2 ++
>> 2 files changed, 43 insertions(+), 3 deletions(-)
>>
>> diff --git a/hw/core/irq.c b/hw/core/irq.c
>> index 03c8cb3..0bcd27b 100644
>> --- a/hw/core/irq.c
>> +++ b/hw/core/irq.c
>> @@ -23,8 +23,13 @@
>> */
>> #include "qemu-common.h"
>> #include "hw/irq.h"
>> +#include "qom/object.h"
>> +
>> +#define IRQ(obj) OBJECT_CHECK(struct IRQState, (obj), TYPE_IRQ)
>>
>> struct IRQState {
>> + Object parent_obj;
>> +
>> qemu_irq_handler handler;
>> void *opaque;
>> int n;
>> @@ -38,6 +43,14 @@ void qemu_set_irq(qemu_irq irq, int level)
>> irq->handler(irq->opaque, irq->n, level);
>> }
>>
>> +static void irq_nonfirst_free(void *obj)
>> +{
>> + struct IRQState *s = obj;
>> +
>> + /* Unreference the first IRQ in this array */
>> + object_unref(OBJECT(s - s->n));
>> +}
>> +
>> qemu_irq *qemu_extend_irqs(qemu_irq *old, int n_old, qemu_irq_handler handler,
>> void *opaque, int n)
>> {
>> @@ -51,11 +64,23 @@ qemu_irq *qemu_extend_irqs(qemu_irq *old, int n_old, qemu_irq_handler handler,
>> s = old ? g_renew(qemu_irq, old, n + n_old) : g_new(qemu_irq, n);
>> p = old ? g_renew(struct IRQState, s[0], n + n_old) :
>> g_new(struct IRQState, n);
>
> So using g_renew on the actual object storage is very fragile, as it
> means you cannot reliably take pointers to the objects. I think
> however this whole issue could be simplified by de-arrayifying the
> whole thing, and treating IRQs individually (interdiff):
>
> qemu_irq *qemu_extend_irqs(qemu_irq *old, int n_old, qemu_irq_handler handler,
> void *opaque, int n)
> {
> qemu_irq *s;
> - struct IRQState *p;
> int i;
>
> if (!old) {
> n_old = 0;
> }
> s = old ? g_renew(qemu_irq, old, n + n_old) : g_new(qemu_irq, n);
> - p = old ? g_renew(struct IRQState, s[0], n + n_old) :
> - g_new(struct IRQState, n);
> - memset(p + n_old, 0, n * sizeof(*p));
> for (i = 0; i < n + n_old; i++) {
> if (i >= n_old) {
> - Object *obj;
> -
> - object_initialize(p, sizeof(*p), TYPE_IRQ);
> - p->handler = handler;
> - p->opaque = opaque;
> - p->n = i;
> - obj = OBJECT(p);
> - /* Let the first IRQ clean them all up */
> - if (unlikely(i == 0)) {
> - obj->free = g_free;
> - } else {
> - object_ref(OBJECT(s[0]));
> - obj->free = irq_nonfirst_free;
> - }
> + s[i] = qemu_allocate_irq(handler, opaque, i);
> }
> - s[i] = p;
> - p++;
> }
> return s;
>
> The system for freeing may need some thought, and I wonder if their
> are API clients out there assuming the IRQ storage elements are
> contiguous (if there are they have too much internal knowledge and
> need to be fixed).
>
> But with this change these objects are now usable with links and canon
> paths etc.
>
> Will roll into V2 of this patch.
Negative!
I was well aware of the two g_renew()s, one of which affects the
objects. However I figured, as long as no one has a pointer to those
objects it should just continue work (otherwise the pre-QOM pointers
would've broken, too -> separate issue) - and so far I haven't found a
test case that doesn't work as is.
So while I agree that we should refactor this, your series does iirc not
include my genuine qemu_irq* fixes either, and I reported at least two
callers of qemu_free_irqs() remaining, in serial-pci.c among others, so
your diff above is not yet okay - it would leak any non-first IRQState.
Which is why I do these odd object_{ref,unref}() tricks -
qemu_free_irqs() cannot tell how many IRQs there are to be freed. And
while your use of qemu_allocate_irq() gives them the normal oc->free =
g_free for freeing them individually, you do not unref them anywhere, so
it will never happen.
Instead of squashing this into my patch I suggest you build upon master
plus my first two cleanup patches and get rid of the remaining
qemu_free_irqs()s altogether, then we can much more sanely refactor this
code and get it in shortly.
Cheers,
Andreas
--
SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany
GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer; HRB 16746 AG Nürnberg
next prev parent reply other threads:[~2014-05-19 9:13 UTC|newest]
Thread overview: 31+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-05-16 1:49 [Qemu-devel] [RFC v1 00/25] Memory and GPIO QOMification Peter Crosthwaite
2014-05-16 1:50 ` [Qemu-devel] [RFC v1 01/25] qdev: Implement named GPIOs Peter Crosthwaite
2014-05-16 1:51 ` [Qemu-devel] [RFC v1 02/25] memory: Simplify mr_add_subregion() if-else Peter Crosthwaite
2014-05-16 1:51 ` [Qemu-devel] [RFC v1 03/25] memory: Coreify subregion add functionality Peter Crosthwaite
2014-05-16 1:52 ` [Qemu-devel] [RFC v1 04/25] memory: MemoryRegion: QOMify Peter Crosthwaite
2014-05-16 1:52 ` [Qemu-devel] [RFC v1 05/25] memory: MemoryRegion: Add contained flag Peter Crosthwaite
2014-05-16 1:53 ` [Qemu-devel] [RFC v1 06/25] memory: MemoryRegion: Add container and addr props Peter Crosthwaite
2014-05-16 1:53 ` [Qemu-devel] [RFC v1 07/25] memory: MemoryRegion: factor out memory region re-adder Peter Crosthwaite
2014-05-16 1:54 ` [Qemu-devel] [RFC v1 08/25] memory: MemoryRegion: Add may-overlap and priority props Peter Crosthwaite
2014-05-26 1:44 ` Peter Crosthwaite
2014-05-16 1:55 ` [Qemu-devel] [RFC v1 09/25] memory: MemoryRegion: Add size property Peter Crosthwaite
2014-05-16 1:55 ` [Qemu-devel] [RFC v1 10/25] exec: Parent root MRs to the machine Peter Crosthwaite
2014-05-16 1:56 ` [Qemu-devel] [RFC v1 11/25] irq: Slim conversion of qemu_irq to QOM [WIP] Peter Crosthwaite
2014-05-19 1:52 ` Peter Crosthwaite
2014-05-19 9:13 ` Andreas Färber [this message]
2014-05-19 10:22 ` Peter Crosthwaite
2014-05-16 1:56 ` [Qemu-devel] [RFC v1 12/25] qdev: gpio: Don't allow name share between I and O Peter Crosthwaite
2014-05-16 1:57 ` [Qemu-devel] [RFC v1 13/25] qdev: gpio: Register GPIO inputs as child objects Peter Crosthwaite
2014-05-16 1:57 ` [Qemu-devel] [RFC v1 14/25] qdev: gpio: Register GPIO outputs as QOM links Peter Crosthwaite
2014-05-16 1:58 ` [Qemu-devel] [RFC v1 15/25] qdev: gpio: Re-impement qdev_connect_gpio QOM style Peter Crosthwaite
2014-05-16 1:59 ` [Qemu-devel] [RFC v1 16/25] qom: object_property_set/get: Add child recursion Peter Crosthwaite
2014-05-16 1:59 ` [Qemu-devel] [RFC v1 17/25] sysbus: Use TYPE_DEVICE GPIO functionality Peter Crosthwaite
2014-05-19 1:59 ` Peter Crosthwaite
2014-05-16 2:00 ` [Qemu-devel] [RFC v1 18/25] sysbus: Rework sysbus_mmio_map to use mr QOMification Peter Crosthwaite
2014-05-16 2:00 ` [Qemu-devel] [RFC v1 19/25] sysbus: Setup memory regions as dynamic props Peter Crosthwaite
2014-05-16 2:01 ` [Qemu-devel] [RFC v1 20/25] sysbus: Enable hotplug Peter Crosthwaite
2014-05-16 2:01 ` [Qemu-devel] [RFC v1 21/25] microblaze: s3adsp: Expand UART creator Peter Crosthwaite
2014-05-16 2:02 ` [Qemu-devel] [RFC v1 22/25] microblaze: s3adsp: Parent devices with sane names Peter Crosthwaite
2014-05-16 2:03 ` [Qemu-devel] [RFC v1 23/25] timer: xilinx_timer: Convert to realize() Peter Crosthwaite
2014-05-16 2:03 ` [Qemu-devel] [RFC v1 24/25] timer: xilinx_timer: init MMIO ASAP Peter Crosthwaite
2014-05-16 2:04 ` [Qemu-devel] [RFC v1 25/25] TEST: microblaze: s3adsp: Remove timer 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=5379CB47.5040703@suse.de \
--to=afaerber@suse.de \
--cc=edgar.iglesias@xilinx.com \
--cc=pbonzini@redhat.com \
--cc=peter.crosthwaite@xilinx.com \
--cc=peter.maydell@linaro.org \
--cc=qemu-devel@nongnu.org \
/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).