Minoru Usui <u...@mxm.nes.nec.co.jp> writes: > 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.
qemu_device_opts holds the currently defined device configurations. A device configuration becomes defined the moment its QemuOpts get created (for -device and device_add: right when the argument gets parsed, which is *before* the device gets created, let alone plugged). It ceases to be defined when device creation fails, or when the device is deleted after unplug completed. qemu_device_opts is *not* the set of devices currently plugged in. That information is encoded in the device tree.
