Re: [Qemu-block] [Question] How can we confirm hot-plug disk succesfully?
在 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
Re: [Qemu-block] [Question] How can we confirm hot-plug disk succesfully?
Am 19.06.2017 um 12:27 hat Xie Changlong geschrieben: > 在 6/19/2017 3:27 PM, Kevin Wolf 写道: > >Am 18.06.2017 um 09:21 hat Xie Changlong geschrieben: > >>In device hot-remove scenario, if we don't probe acpiphp module on > >>the guest, 'device_del' will never emit DEVICE_DELETED event(because > >>guest will not write to __EJ0) . So we can confirm that hot-remove > >>failed. But IIUC, there is no event such as DEVICE_ADDED, so > >>1) How can we confirm hotplug('device_add') successfully? > >>2) It seems when hot-plug disk, we don't care acpiphp module status > >>on the guest, am I right? > >>3) Why there is no DEVICE_ADDED like event? > > > >device_add doesn't need guest cooperation, so it is immediately > >completed when the QMP command returns success. > > > > That's what i though too. But I have a question, if we don't proble > acpiphp on the guest, and execute below commands: > > Hot plug: > (qemu) drive_add 0 > file=/resource/changlox/test.raw,id=drive-virtio-disk1,if=none > (qemu) device_add virtio-blk-pci,drive=drive-virtio-disk1,id=virtio-disk1 > > Hot remove: > (qemu) device_del virtio-disk1 > (qemu) drive_del drive-virtio-disk1 > (qemu) qom-list /machine/peripheral > type (string) > virtio-disk1 (child) > (qemu) info block > foo (#block122): suse1.qcow2 (qcow2) > Cache mode: writeback, direct > Backing file: suse.qcow2.orgin (chain depth: 1) > > ide1-cd0: [not inserted] > Removable device: not locked, tray closed > > floppy0: [not inserted] > Removable device: not locked, tray closed > > sd0: [not inserted] > Removable device: not locked, tray closed > (qemu) drive_add 0 > file=/resource/changlox/test.raw,id=drive-virtio-disk1,if=none > Duplicate ID 'drive-virtio-disk1' for drive > > '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? > 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. Kevin
Re: [Qemu-block] [Question] How can we confirm hot-plug disk succesfully?
在 6/19/2017 3:27 PM, Kevin Wolf 写道: Am 18.06.2017 um 09:21 hat Xie Changlong geschrieben: In device hot-remove scenario, if we don't probe acpiphp module on the guest, 'device_del' will never emit DEVICE_DELETED event(because guest will not write to __EJ0) . So we can confirm that hot-remove failed. But IIUC, there is no event such as DEVICE_ADDED, so 1) How can we confirm hotplug('device_add') successfully? 2) It seems when hot-plug disk, we don't care acpiphp module status on the guest, am I right? 3) Why there is no DEVICE_ADDED like event? device_add doesn't need guest cooperation, so it is immediately completed when the QMP command returns success. That's what i though too. But I have a question, if we don't proble acpiphp on the guest, and execute below commands: Hot plug: (qemu) drive_add 0 file=/resource/changlox/test.raw,id=drive-virtio-disk1,if=none (qemu) device_add virtio-blk-pci,drive=drive-virtio-disk1,id=virtio-disk1 Hot remove: (qemu) device_del virtio-disk1 (qemu) drive_del drive-virtio-disk1 (qemu) qom-list /machine/peripheral type (string) virtio-disk1 (child) (qemu) info block foo (#block122): suse1.qcow2 (qcow2) Cache mode: writeback, direct Backing file: suse.qcow2.orgin (chain depth: 1) ide1-cd0: [not inserted] Removable device: not locked, tray closed floppy0: [not inserted] Removable device: not locked, tray closed sd0: [not inserted] Removable device: not locked, tray closed (qemu) drive_add 0 file=/resource/changlox/test.raw,id=drive-virtio-disk1,if=none Duplicate ID 'drive-virtio-disk1' for drive 'info block' shows nothing, but we can't add drive who's id is'drive-virtio-disk1' too。 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. Kevin -- Thanks -Xie
Re: [Qemu-block] [Question] How can we confirm hot-plug disk succesfully?
Am 18.06.2017 um 09:21 hat Xie Changlong geschrieben: > In device hot-remove scenario, if we don't probe acpiphp module on > the guest, 'device_del' will never emit DEVICE_DELETED event(because > guest will not write to __EJ0) . So we can confirm that hot-remove > failed. But IIUC, there is no event such as DEVICE_ADDED, so > 1) How can we confirm hotplug('device_add') successfully? > 2) It seems when hot-plug disk, we don't care acpiphp module status > on the guest, am I right? > 3) Why there is no DEVICE_ADDED like event? device_add doesn't need guest cooperation, so it is immediately completed when the QMP command returns success. Kevin
Re: [Qemu-block] [Question] How can we confirm hot-plug disk succesfully?
Resend 在 6/18/2017 3:21 PM, Xie Changlong 写道: Hi all In device hot-remove scenario, if we don't probe acpiphp module on the guest, 'device_del' will never emit DEVICE_DELETED event(because guest will not write to __EJ0) . So we can confirm that hot-remove failed. But IIUC, there is no event such as DEVICE_ADDED, so 1) How can we confirm hotplug('device_add') successfully? 2) It seems when hot-plug disk, we don't care acpiphp module status on the guest, am I right? 3) Why there is no DEVICE_ADDED like event? Any answer would be appreciated, thanks. -- Thanks -Xie
[Qemu-block] [Question] How can we confirm hot-plug disk succesfully?
Hi all In device hot-remove scenario, if we don't probe acpiphp module on the guest, 'device_del' will never emit DEVICE_DELETED event(because guest will not write to __EJ0) . So we can confirm that hot-remove failed. But IIUC, there is no event such as DEVICE_ADDED, so 1) How can we confirm hotplug('device_add') successfully? 2) It seems when hot-plug disk, we don't care acpiphp module status on the guest, am I right? 3) Why there is no DEVICE_ADDED like event? Any answer would be appreciated, thanks. -- Thanks -Xie