qemu-devel.nongnu.org archive mirror
 help / color / mirror / Atom feed
From: Corey Minyard <minyard@acm.org>
To: Paolo Bonzini <pbonzini@redhat.com>, qemu-devel@nongnu.org
Cc: "Marc-André Lureau" <mlureau@redhat.com>
Subject: Re: [Qemu-devel] [PATCH v3 0/4] Plug some memory leaks on unrealize
Date: Sat, 23 Jul 2016 13:04:55 -0500	[thread overview]
Message-ID: <5793B1C7.4020106@acm.org> (raw)
In-Reply-To: <8ff708c8-65f7-0272-3f55-f6507af7ae7d@redhat.com>

On 07/23/2016 10:16 AM, Paolo Bonzini wrote:
>
> On 23/07/2016 15:18, Corey Minyard wrote:
>> On 07/23/2016 02:46 AM, Paolo Bonzini wrote:
>>> On 22/07/2016 21:50, minyard@acm.org wrote:
>>>> This has kind of opened a can of worms for me, though.  Looking
>>>> at a lot of the devices, there is no unrealize function and that
>>>> can leave a lot of things hanging.  And for ISA bus devices, there
>>>> is no way to unregister ports.
>>> Right, this is because they aren't hotpluggable.
>>>
>>> I should dig out the huge patchset I had to make timers statically
>>> allocated...
>>>
>>> Paolo
>> Am I correct in saying, then, that instead of adding a finalize
>> function to the IPMI BMC, we should instead make it not hot
>> pluggable?  And then the rest of my patches are not really
>> relevant.  I already have a function to set hotpluggable to
>> false for the BMCs, I can post that.
> If they are ISA devices they should already not be hot-unpluggable,
> because none of the ISA bridges implements HotplugHandler.  Because
> that's just the way the bus works, it shouldn't be an issue.

It's not exactly an ISA device.  This is a BMC that an ISA device
hooks to, but it's a separate device.

>>  From what I have seen, you can unrealize devices using the
>> API, even if they are not hot pluggable, by setting the realized
>> bool.  Is that ok?
> It's not great, but it's not a big deal either.
>
> The original idea behind "realize" was to have it as a sort of Vcc pin
> where a false/true pulse would work as a reset, but this never
> materialized.  Now the true->false transition on realize is really only
> used as part of a full guest-triggered hot-unplug sequence, which is
> guest->hotplug_handler_unplug->(method call)->object_unparent.
>
> Because all HotplugHandlers call object_unparent, which in turn ends up
> freeing the object, a false->true->false transition on realized (and
> thus the timer leak) is not guest-triggerable.
>
> There are various fixes, including:
>
> - making the device non-hotpluggable
>
> - moving the timer_new and timer_free respectively to instance_init and
> instance_finalize
>
> - making the timer static, which requires some small changes in the
> timer API.  Most of the last bullet is scriptable with Coccinelle.
>
> Right now I'd just do #2 or don't bother.
>
> Paolo
I think I'm going to opt for #1, because the device isn't hot
pluggable and if you try to unplug it qemu will crash.

-corey

      reply	other threads:[~2016-07-23 18:05 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-07-22 19:50 [Qemu-devel] [PATCH v3 0/4] Plug some memory leaks on unrealize minyard
2016-07-22 19:50 ` [Qemu-devel] [PATCH v3 1/4] ipmi_bmc_sim: Remove an unnecessary mutex minyard
2016-07-22 19:50 ` [Qemu-devel] [PATCH v3 2/4] wdt_i6300esb: Free timer minyard
2016-07-22 19:50 ` [Qemu-devel] [PATCH v3 3/4] wdt_ib700: " minyard
2016-07-22 19:50 ` [Qemu-devel] [PATCH v3 4/4] ipmi_bmc_sim: Add a proper unrealize function minyard
2016-07-23  7:46 ` [Qemu-devel] [PATCH v3 0/4] Plug some memory leaks on unrealize Paolo Bonzini
2016-07-23 13:18   ` Corey Minyard
2016-07-23 15:16     ` Paolo Bonzini
2016-07-23 18:04       ` Corey Minyard [this message]

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=5793B1C7.4020106@acm.org \
    --to=minyard@acm.org \
    --cc=mlureau@redhat.com \
    --cc=pbonzini@redhat.com \
    --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).