All of lore.kernel.org
 help / color / mirror / Atom feed
From: Markus Armbruster <armbru@redhat.com>
To: Paolo Bonzini <pbonzini@redhat.com>
Cc: "Peter Maydell" <peter.maydell@linaro.org>,
	"Daniel P. Berrangé" <berrange@redhat.com>,
	zhanghailiang <zhang.zhanghailiang@huawei.com>,
	"Pan Nengyuan" <pannengyuan@huawei.com>,
	"Mark Cave-Ayland" <mark.cave-ayland@ilande.co.uk>,
	"Laurent Vivier" <laurent@vivier.eu>,
	"QEMU Developers" <qemu-devel@nongnu.org>,
	"Euler Robot" <euler.robot@huawei.com>,
	"Eduardo Habkost" <ehabkost@redhat.com>
Subject: Re: [PATCH v4 2/3] mac_via: fix incorrect creation of mos6522 device in mac_via
Date: Mon, 16 Mar 2020 07:03:24 +0100	[thread overview]
Message-ID: <87mu8g3kgj.fsf@dusky.pond.sub.org> (raw)
In-Reply-To: <3f512e33-5875-eee4-bbe8-61e7b313743d@redhat.com> (Paolo Bonzini's message of "Sun, 15 Mar 2020 18:58:14 +0100")

Paolo Bonzini <pbonzini@redhat.com> writes:

> On 15/03/20 15:56, Markus Armbruster wrote:
>>>
>>> The question is why they are not, i.e. where does the above reasoning break.
>> I don't know.  But let's for the sake of the argument assume this
>> actually worked.  Asking for help in the monitor then *still* has side
>> effects visible in the time span between .instance_init() and
>> finalization.
>> 
>> Why is that harmless?
>
> I don't really have an answer, but if that is a problem we could change
> "info qtree" to skip non-realized devices.

Can we convince ourselves that "info qtree" is the *only* way to observe
these side effects?

If yes, a hack to ignore unrealized devices "fixes" the problem.

If no, it sweeps it under the rug.



  reply	other threads:[~2020-03-16  6:09 UTC|newest]

Thread overview: 44+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-03-05  6:54 [PATCH v4 0/3] delay timer_new from init to realize to fix memleaks Pan Nengyuan
2020-03-05  6:46 ` no-reply
2020-03-05  6:54 ` [PATCH v4 1/3] s390x: fix memleaks in cpu_finalize Pan Nengyuan
2020-03-05  8:34   ` David Hildenbrand
2020-03-05  9:03     ` Pan Nengyuan
2020-03-05  6:54 ` [PATCH v4 2/3] mac_via: fix incorrect creation of mos6522 device in mac_via Pan Nengyuan
2020-03-05  7:10   ` Pan Nengyuan
2020-03-05  7:18   ` Pan Nengyuan
2020-03-08 13:29   ` Peter Maydell
2020-03-09  0:56     ` Pan Nengyuan
2020-03-09  9:21       ` Peter Maydell
2020-03-09 10:02         ` Pan Nengyuan
2020-03-09 10:10           ` Peter Maydell
2020-03-09 12:34             ` Markus Armbruster
2020-03-09 12:51               ` Pan Nengyuan
2020-03-09 14:14                 ` Markus Armbruster
2020-03-09 16:16                   ` Mark Cave-Ayland
2020-03-10  0:34                     ` Pan Nengyuan
2020-03-10  9:07             ` Markus Armbruster
2020-03-10  9:41               ` Peter Maydell
2020-03-10 12:38               ` BALATON Zoltan
2020-03-14 13:19               ` Mark Cave-Ayland
2020-03-14 14:03                 ` Paolo Bonzini
2020-03-15 14:56                   ` Markus Armbruster
2020-03-15 17:58                     ` Paolo Bonzini
2020-03-16  6:03                       ` Markus Armbruster [this message]
2020-03-16  8:43                         ` Paolo Bonzini
2020-03-18 13:02                           ` Markus Armbruster
2020-03-18 13:21                             ` Paolo Bonzini
2020-03-18 14:58                               ` Peter Maydell
2020-03-18 15:06                               ` Markus Armbruster
2020-03-18 16:44                                 ` Paolo Bonzini
2020-03-19  7:01                                   ` Markus Armbruster
2020-03-19  8:43                                     ` Paolo Bonzini
2020-04-02 13:40                                       ` Markus Armbruster
2020-03-15 15:16                 ` Markus Armbruster
2020-03-05  6:54 ` [PATCH v4 3/3] hw/misc/mos6522: move timer_new from init() into realize() to avoid memleaks Pan Nengyuan
2020-03-05 22:56   ` David Gibson
2020-03-06  0:50     ` Pan Nengyuan
2020-03-13  6:50     ` David Gibson
2020-03-08 11:58 ` [PATCH v4 0/3] delay timer_new from init to realize to fix memleaks Mark Cave-Ayland
2020-03-08 13:39   ` Peter Maydell
2020-03-09  0:49     ` Pan Nengyuan
2020-03-09 16:14     ` Mark Cave-Ayland

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=87mu8g3kgj.fsf@dusky.pond.sub.org \
    --to=armbru@redhat.com \
    --cc=berrange@redhat.com \
    --cc=ehabkost@redhat.com \
    --cc=euler.robot@huawei.com \
    --cc=laurent@vivier.eu \
    --cc=mark.cave-ayland@ilande.co.uk \
    --cc=pannengyuan@huawei.com \
    --cc=pbonzini@redhat.com \
    --cc=peter.maydell@linaro.org \
    --cc=qemu-devel@nongnu.org \
    --cc=zhang.zhanghailiang@huawei.com \
    /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.