Hi, William, Markus and other people. On Wed, 23 Feb 2011 10:42:02 +0100 William Dauchy <wdau...@gmail.com> wrote:
> Hi Minoru, > > On Tue, Feb 15, 2011 at 3:32 AM, Minoru Usui <u...@mxm.nes.nec.co.jp> wrote: > > I can reproduce, too. > > But strangely, it don't occur in case of loading acpiphp driver > > to the guest VM on below environment. > > > > Host : RHEL6.0 > > Guest: RHEL5.5 > > > > Unfortunately, I'm not familiar with qemu-kvm. > > I investigated below questions about this problem, but I couldn't resolve > > them. > > > > - How to call qdev_free() asynchronously. (How should we fix this problem) > > - Why it don't occur with acpiphp driver > > > > If anyone knows answer of above questions or its clue, please let me know. > > If fact this is not a bug. > `qdev_free` is called when the acpi detach succeed in `pciej_write`. > The virtual machine has to correctly support acpi signals. > Please read the explanation from Markus Armbruster on > http://lists.nongnu.org/archive/html/qemu-devel/2011-02/msg02637.html William, Thank you for your help and telling me about it. Markus, Thank you for your detailed explanation. Basically, I understand behaviour of device_del command. The result of pci hotunplug depends on behaviour of guest OS, but device_del command doesn't wait hotunplug's result. May I ask you a question? Which device does qemu_device_opts manage? just hotplugged to virtual machine? Or hotplugged to guest OS? By the present implementation, device_add command adds qemu_device_opts immediately, whether guest OS can hotplug the device or not. Nevertheless, device_del command waits for the device appropriately until it is hotunplugged by the guest OS. By Markus's explanation, device_del command can't wait for the device which hotunplugged from guest OS. So, I feel it's better that qemu_device_opts manages the device which hotplugged to guest OS. If I am wrong, please let me know. -- Minoru Usui <u...@mxm.nes.nec.co.jp>
