qemu-devel.nongnu.org archive mirror
 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 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).