From: Xie Changlong <xiechanglong.d@gmail.com>
To: Kevin Wolf <kwolf@redhat.com>
Cc: qemu-devel@nongnu.org, qemu-block@nongnu.org,
Paolo Bonzini <pbonzini@redhat.com>,
"Michael S. Tsirkin" <mst@redhat.com>,
Stefan Hajnoczi <stefanha@redhat.com>,
Fam Zheng <famz@redhat.com>, Max Reitz <mreitz@redhat.com>,
armbru@redhat.com
Subject: Re: [Qemu-devel] [Question] How can we confirm hot-plug disk succesfully?
Date: Thu, 22 Jun 2017 09:12:03 +0800 [thread overview]
Message-ID: <1295c586-859f-23d5-67c5-e1d730ef63b5@gmail.com> (raw)
In-Reply-To: <20170619104915.GC6113@noname.redhat.com>
在 6/19/2017 6:49 PM, Kevin Wolf 写道:
>> 'info block' shows nothing, but we can't add drive who's id
>> is'drive-virtio-disk1' too.
> Yes, the old BlockBackend is only fully freed when the guest actually
> unplugs the device. Specifically, we would have to free the QemuOpts
> in DriveInfo that keeps the ID reserved. Currently, it is only freed
> when the BlockBackend is destroyed:
>
> blockdev_auto_del()
> blk_unref()
> blk_delete()
> drive_info_del()
>
> We can't free the DriveInfo earlier because it's still needed while the
> guest device is still alive.
>
> I'm not sure, but it may be possible to free just the QemuOpts in
> monitor_remove_blk(), so that the ID can immediately be reused.
>
> Markus, would you know?
>
Hi, all. Any ideas?
>> There is a more serious situation, we
>> could*never* destory device memory with 'device_del', it's memory
>> leak to me if the guest os never support hot-plug and the user don't
>> know this information.
> The user sees that they never get a DEVICE_REMOVED event, so in some way
> the do know about it.
But the useless memory is always there and no way to free it, although
we known that.
BTW, is it possible to force destroy the BlockBackend in this situation?
--
Thanks
-Xie
next prev parent reply other threads:[~2017-06-22 1:12 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-06-18 7:21 [Qemu-devel] [Question] How can we confirm hot-plug disk succesfully? Xie Changlong
2017-06-19 4:09 ` Xie Changlong
2017-06-19 7:27 ` Kevin Wolf
2017-06-19 10:27 ` Xie Changlong
2017-06-19 10:49 ` Kevin Wolf
2017-06-22 1:12 ` Xie Changlong [this message]
2017-06-22 13:56 ` Markus Armbruster
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=1295c586-859f-23d5-67c5-e1d730ef63b5@gmail.com \
--to=xiechanglong.d@gmail.com \
--cc=armbru@redhat.com \
--cc=famz@redhat.com \
--cc=kwolf@redhat.com \
--cc=mreitz@redhat.com \
--cc=mst@redhat.com \
--cc=pbonzini@redhat.com \
--cc=qemu-block@nongnu.org \
--cc=qemu-devel@nongnu.org \
--cc=stefanha@redhat.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 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).