From: Peter Maydell <peter.maydell@linaro.org>
To: qemu-devel@nongnu.org
Cc: Laurent Vivier <laurent@vivier.eu>
Subject: [PATCH 0/2] m68k/q800: make the GLUE chip a QOM device
Date: Fri, 6 Nov 2020 23:51:07 +0000 [thread overview]
Message-ID: <20201106235109.7066-1-peter.maydell@linaro.org> (raw)
This series is 6.0 material really I think. It's a bit of cleanup
prompted by a Coverity issue, CID 1421883. There are another half
dozen or so similar issues, where Coverity is complaining that we
allocate an array of qemu_irqs with qemu_allocate_irqs() in a board
init function -- in this case the 'pic' array in q800_init() -- and
then we return from the board init function and the memory is leaked,
in the sense that nobody has a pointer to it any more.
The leak isn't real, in that board init functions are called only
once, and the array of qemu_irqs really does need to stay around for
the life of the simulation, so these are pretty much insignificant
as Coverity issues go. But this coding style which uses a free-floating
set of qemu_irqs is not very "modern QEMU", so the issues act as
a nudge that we should clean the code up by encapsulating the
interrupt-line behaviour in a QOM device. In the q800 case there
actually is already a GLUEState struct, it just needs to be turned
into a QOM device with GPIO input lines. Patch 2 does that.
Patch 1 fixes a bug I noticed while doing this work -- it's
not valid to connect two qemu_irq lines directly to the same
input (here both ESCC irq lines go to pic[3]) because it produces
weird behaviour like "both lines are asserted but the device
consuming the interrupt sees the line deassert when one of the
two inputs goes low, rather than only when they both go low".
You need to put an explicit OR gate in, assuming that logical-OR
is the desired behaviour, which it usually is.
Tested only with 'make check' and 'make check-acceptance',
but the latter does have a q800 bootup test.
thanks
-- PMM
Peter Maydell (2):
hw/m68k/q800: Don't connect two qemu_irqs directly to the same input
hw/m68k/q800.c: Make the GLUE chip an actual QOM device
hw/m68k/q800.c | 92 ++++++++++++++++++++++++++++++++++++++++++-------
hw/m68k/Kconfig | 1 +
2 files changed, 80 insertions(+), 13 deletions(-)
--
2.20.1
next reply other threads:[~2020-11-06 23:53 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-11-06 23:51 Peter Maydell [this message]
2020-11-06 23:51 ` [PATCH 1/2] hw/m68k/q800: Don't connect two qemu_irqs directly to the same input Peter Maydell
2020-11-07 14:52 ` Philippe Mathieu-Daudé
2020-11-07 15:11 ` Philippe Mathieu-Daudé
2020-11-10 13:07 ` Mark Cave-Ayland
2020-11-07 16:01 ` Laurent Vivier
2020-11-06 23:51 ` [PATCH 2/2] hw/m68k/q800.c: Make the GLUE chip an actual QOM device Peter Maydell
2020-11-07 16:15 ` Laurent Vivier
2020-11-09 14:14 ` Philippe Mathieu-Daudé
2020-11-09 14:18 ` Peter Maydell
2020-12-11 14:11 ` [PATCH 0/2] m68k/q800: make the GLUE chip a " Peter Maydell
2020-12-12 17:07 ` Laurent Vivier
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=20201106235109.7066-1-peter.maydell@linaro.org \
--to=peter.maydell@linaro.org \
--cc=laurent@vivier.eu \
--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).