All of lore.kernel.org
 help / color / mirror / Atom feed
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

  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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.