From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:46055) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bQIi7-0002qA-IN for qemu-devel@nongnu.org; Thu, 21 Jul 2016 14:28:40 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1bQIi2-0001cO-Mf for qemu-devel@nongnu.org; Thu, 21 Jul 2016 14:28:38 -0400 Received: from mx6-phx2.redhat.com ([209.132.183.39]:39555) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bQIi2-0001cG-DE for qemu-devel@nongnu.org; Thu, 21 Jul 2016 14:28:34 -0400 Date: Thu, 21 Jul 2016 14:28:33 -0400 (EDT) From: =?utf-8?Q?Marc-Andr=C3=A9?= Lureau Message-ID: <1575824847.7153299.1469125713237.JavaMail.zimbra@redhat.com> In-Reply-To: <20160721180714.GM3337@thinpad.lan.raisama.net> References: <20160719085432.4572-1-marcandre.lureau@redhat.com> <20160719085432.4572-25-marcandre.lureau@redhat.com> <20160721171843.GC11412@thinpad.lan.raisama.net> <353979551.7143571.1469122055548.JavaMail.zimbra@redhat.com> <20160721180714.GM3337@thinpad.lan.raisama.net> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Subject: Re: [Qemu-devel] [PATCH 24/37] pc: keep gsi reference List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Eduardo Habkost Cc: marcandre lureau , qemu-devel@nongnu.org, "Michael S. Tsirkin" Hi ----- Original Message ----- > On Thu, Jul 21, 2016 at 01:27:35PM -0400, Marc-Andr=C3=A9 Lureau wrote: > > Hi > >=20 > > ----- Original Message ----- > > > On Tue, Jul 19, 2016 at 12:54:19PM +0400, marcandre.lureau@redhat.com > > > wrote: > > > > From: Marc-Andr=C3=A9 Lureau > > > >=20 > > > > Further cleanup would need to call qemu_free_irq() at the appropria= te > > > > time, but for now this silences ASAN about direct leaks. > > > >=20 > > > > Signed-off-by: Marc-Andr=C3=A9 Lureau > > >=20 > > > Is there a way to make ASAN happy without having to add a field > > > to MachineState that we're not going to use for anything? > >=20 > > Well, the plan is rather to release it when no longer needed. > > Would it be fine to call qemu_free_irqs() in > > machine_finalize()? >=20 > It would be fine, I guess, but it looks pointless if we have lots > of other resources allocated during PC machine initialization > that are never released. The main point, right now, is to have no direct leaks when running ASAN or = valgrind, as they hide new introduced leaks that may be much worse. (it wou= ld also be good if we had no indirect leaks either, as this may also grow o= ver time) > But, see additional comment below: >=20 > >=20 > > >=20 > > > > --- > > > > hw/i386/pc_piix.c | 1 + > > > > hw/i386/pc_q35.c | 1 + > > > > include/hw/boards.h | 1 + > > > > 3 files changed, 3 insertions(+) > > > >=20 > > > > diff --git a/hw/i386/pc_piix.c b/hw/i386/pc_piix.c > > > > index a07dc81..b2db274 100644 > > > > --- a/hw/i386/pc_piix.c > > > > +++ b/hw/i386/pc_piix.c > > > > @@ -190,6 +190,7 @@ static void pc_init1(MachineState *machine, > > > > } else { > > > > gsi =3D qemu_allocate_irqs(gsi_handler, gsi_state, > > > > GSI_NUM_PINS); > > > > } > > > > + machine->gsi =3D gsi; > > > > =20 > > > > if (pcmc->pci_enabled) { > > > > pci_bus =3D i440fx_init(host_type, > > > > diff --git a/hw/i386/pc_q35.c b/hw/i386/pc_q35.c > > > > index c5e8367..5dfb14f 100644 > > > > --- a/hw/i386/pc_q35.c > > > > +++ b/hw/i386/pc_q35.c > > > > @@ -158,6 +158,7 @@ static void pc_q35_init(MachineState *machine) > > > > } else { > > > > gsi =3D qemu_allocate_irqs(gsi_handler, gsi_state, > > > > GSI_NUM_PINS); > > > > } > > > > + machine->gsi =3D gsi; > > > > =20 > > > > /* create pci host bus */ > > > > q35_host =3D Q35_HOST_DEVICE(qdev_create(NULL, > > > > TYPE_Q35_HOST_DEVICE)); > > > > diff --git a/include/hw/boards.h b/include/hw/boards.h > > > > index e46a744..289ba52 100644 > > > > --- a/include/hw/boards.h > > > > +++ b/include/hw/boards.h > > > > @@ -139,6 +139,7 @@ struct MachineState { > > > > /*< private >*/ > > > > Object parent_obj; > > > > Notifier sysbus_notifier; > > > > + qemu_irq *gsi; >=20 > If this is used only by PC, doesn't it belong to PCMachineState? right, i'll try to put it there > Anyway, the new field would be very useful to help reduce the > number of parameters of PC initialization functions (by making > them just get a PCMachineState* argument). I would go even Which functions do you have in mind? > further and remove the local 'gsi' variable and replace it with > 'pcms->gsi' everywhere. ok, why not.