[Qemu-devel] [PATCH] Remove a detached device from qemu_device_opts.
Hi, When I tried to attach the interface after detaching the same interface, the virsh command output the following and it failed: # virsh detach-interface Domain01 network --mac 52:54:00:0d:78:92 Interface detached successfully # virsh attach-interface Domain01 network default --mac 52:54:00:0d:78:92 error: Failed to attach interface error: internal error unable to execute QEMU command 'device_add': Duplicate ID 'net0' for device # The reason is that a detached device is not removed from the list "qemu_device_opts", and this patch fixes it. Thanks Ken'ichi Ohmichi Signed-off-by: Ken'ichi Ohmichi --- --- a/hw/qdev.c 2011-01-27 17:42:25.0 +0900 +++ b/hw/qdev.c 2011-01-27 17:43:46.0 +0900 @@ -905,6 +905,8 @@ int do_device_del(Monitor *mon, const QD qerror_report(QERR_DEVICE_NOT_FOUND, id); return -1; } +qemu_opts_del(qemu_opts_find(&qemu_device_opts, id)); + return qdev_unplug(dev); }
Re: [Qemu-devel] [PATCH] Remove a detached device from qemu_device_opts.
On Thu, 2011-01-27 at 18:00 +0900, Ken'ichi Ohmichi wrote: > Hi, > > When I tried to attach the interface after detaching the same interface, > the virsh command output the following and it failed: > > # virsh detach-interface Domain01 network --mac 52:54:00:0d:78:92 > Interface detached successfully > > # virsh attach-interface Domain01 network default --mac 52:54:00:0d:78:92 > error: Failed to attach interface > error: internal error unable to execute QEMU command 'device_add': > Duplicate ID 'net0' for device > # > > The reason is that a detached device is not removed from the list > "qemu_device_opts", and this patch fixes it. > Signed-off-by: Ken'ichi Ohmichi > --- > --- a/hw/qdev.c 2011-01-27 17:42:25.0 +0900 > +++ b/hw/qdev.c 2011-01-27 17:43:46.0 +0900 > @@ -905,6 +905,8 @@ int do_device_del(Monitor *mon, const QD > qerror_report(QERR_DEVICE_NOT_FOUND, id); > return -1; > } > +qemu_opts_del(qemu_opts_find(&qemu_device_opts, id)); > + > return qdev_unplug(dev); > } I successfully applied and tested this patch. It resolves the attach problem. -- William
Re: [Qemu-devel] [PATCH] Remove a detached device from qemu_device_opts.
Hi, On Mon, Feb 7, 2011 at 3:40 PM, William Dauchy wrote: > On Thu, 2011-01-27 at 18:00 +0900, Ken'ichi Ohmichi wrote: >> Hi, >> >> When I tried to attach the interface after detaching the same interface, >> the virsh command output the following and it failed: >> >> # virsh detach-interface Domain01 network --mac 52:54:00:0d:78:92 >> Interface detached successfully >> >> # virsh attach-interface Domain01 network default --mac 52:54:00:0d:78:92 >> error: Failed to attach interface >> error: internal error unable to execute QEMU command 'device_add': >> Duplicate ID 'net0' for device >> # >> >> The reason is that a detached device is not removed from the list >> "qemu_device_opts", and this patch fixes it. >> Signed-off-by: Ken'ichi Ohmichi >> --- >> --- a/hw/qdev.c 2011-01-27 17:42:25.0 +0900 >> +++ b/hw/qdev.c 2011-01-27 17:43:46.0 +0900 >> @@ -905,6 +905,8 @@ int do_device_del(Monitor *mon, const QD >> qerror_report(QERR_DEVICE_NOT_FOUND, id); >> return -1; >> } >> + qemu_opts_del(qemu_opts_find(&qemu_device_opts, id)); >> + >> return qdev_unplug(dev); >> } > > I successfully applied and tested this patch. It resolves the attach > problem. > I was wondering if it was going to be merged upstream? Regards, -- William
Re: [Qemu-devel] [PATCH] Remove a detached device from qemu_device_opts.
At 01/27/2011 05:00 PM, Ken'ichi Ohmichi Write: > > Hi, > > When I tried to attach the interface after detaching the same interface, > the virsh command output the following and it failed: > > # virsh detach-interface Domain01 network --mac 52:54:00:0d:78:92 > Interface detached successfully > > # virsh attach-interface Domain01 network default --mac 52:54:00:0d:78:92 > error: Failed to attach interface > error: internal error unable to execute QEMU command 'device_add': > Duplicate ID 'net0' for device > # I can reproduce this problem. > > The reason is that a detached device is not removed from the list > "qemu_device_opts", and this patch fixes it. The detached device will be removed from the list "qemu_device_opts" in qdev_free() asynchronously. > > > Thanks > Ken'ichi Ohmichi > > > Signed-off-by: Ken'ichi Ohmichi > --- > --- a/hw/qdev.c 2011-01-27 17:42:25.0 +0900 > +++ b/hw/qdev.c 2011-01-27 17:43:46.0 +0900 > @@ -905,6 +905,8 @@ int do_device_del(Monitor *mon, const QD > qerror_report(QERR_DEVICE_NOT_FOUND, id); > return -1; > } > +qemu_opts_del(qemu_opts_find(&qemu_device_opts, id)); > + We can not use qemu_device_opts here, because qemu_device_opts is a static variable in qemu-config.c. We should use qemu_find_opts("device") instead of qemu_device_opts. I test your patch by attach/detach interface, and qemu core dumps. The reason may be that we call qemu_opts_del() twice. Here is the log(/var/log/libvirt/qemu/.log): *** glibc detected *** /usr/libexec/qemu-system-x86_64: free(): invalid pointer: 0x0355f000 *** === Backtrace: = /lib64/libc.so.6[0x351f275676] /usr/libexec/qemu-system-x86_64[0x43e2a6] /usr/libexec/qemu-system-x86_64[0x43f9a0] /usr/libexec/qemu-system-x86_64[0x4400ee] /usr/libexec/qemu-system-x86_64[0x4cb176] /usr/libexec/qemu-system-x86_64[0x5af9f6] /usr/libexec/qemu-system-x86_64[0x4953c1] /usr/libexec/qemu-system-x86_64[0x495dab] /usr/libexec/qemu-system-x86_64[0x43a087] /usr/libexec/qemu-system-x86_64[0x43a5dd] /usr/libexec/qemu-system-x86_64[0x51f8f5] /usr/libexec/qemu-system-x86_64[0x40ad4b] /usr/libexec/qemu-system-x86_64[0x40ae52] /usr/libexec/qemu-system-x86_64[0x585c81] /usr/libexec/qemu-system-x86_64[0x589da7] /lib64/libc.so.6(__libc_start_main+0xfd)[0x351f21ec5d] /usr/libexec/qemu-system-x86_64[0x408a19] === Memory map: 0040-00784000 r-xp 08:06 679152 /usr/libexec/qemu-system-x86_64 00983000-009c9000 rw-p 00383000 08:06 679152 /usr/libexec/qemu-system-x86_64 009c9000-01177000 rw-p 00:00 0 01177000-01178000 rwxp 00:00 0 01178000-011d5000 rw-p 00:00 0 02d32000-03109000 rw-p 00:00 0 03109000-03119000 rw-p 00:00 0 03119000-03134000 rw-p 00:00 0 03134000-03144000 rw-p 00:00 0 03144000-0352c000 rw-p 00:00 0 0352c000-0353c000 rw-p 00:00 0 0353c000-0354f000 rw-p 00:00 0 0354f000-0355f000 rw-p 00:00 0 0355f000-0358 rw-p 00:00 0 4154f000-4954f000 rwxp 00:00 0 328d00-328d038000 r-xp 08:06 394303 /lib64/libgssapi_krb5.so.2.2 328d038000-328d237000 ---p 00038000 08:06 394303 /lib64/libgssapi_krb5.so.2.2 328d237000-328d239000 rw-p 00037000 08:06 394303 /lib64/libgssapi_krb5.so.2.2 328d40-328d453000 r-xp 08:06 685072 /usr/lib64/libssl.so.1.0.0 328d453000-328d653000 ---p 00053000 08:06 685072 /usr/lib64/libssl.so.1.0.0 328d653000-328d65b000 rw-p 00053000 08:06 685072 /usr/lib64/libssl.so.1.0.0 328d80-328d827000 r-xp 08:06 394300 /lib64/libk5crypto.so.3.1 328d827000-328da27000 ---p 00027000 08:06 394300 /lib64/libk5crypto.so.3.1 328da27000-328da29000 rw-p 00027000 08:06 394300 /lib64/libk5crypto.so.3.1 328ec0-328eccf000 r-xp 08:06 394302 /lib64/libkrb5.so.3.3 328eccf000-328eecf000 ---p 000cf000 08:06 394302 /lib64/libkrb5.so.3.3 328eecf000-328eeda000 rw-p 000cf000 08:06 394302 /lib64/libkrb5.so.3.3 328f00-328f003000 r-xp 08:06 394301 /lib64/libcom_err.so.2.1 328f003000-328f202000 ---p 3000 08:06 394301 /lib64/libcom_err.so.2.1 328f202000-328f203000 rw-p 2000 08:06 394301 /lib64/libcom_err.so.2.1 328f40-328f40a000 r-xp 08:06 393785 /lib64/libkrb5support.so.0.1 328f40a000-328f609000 ---p a000 08:06 393785 /lib64/libkrb5support.so.0.1 328f609000-328f60a000 rw-p 9000 08:06 393785 /lib64/libkrb5support.so.0.1 351ea0-351ea1e000 r-xp 000
Re: [Qemu-devel] [PATCH] Remove a detached device from qemu_device_opts.
Hi, On Mon, 14 Feb 2011 14:19:56 +0800 Wen Congyang wrote: > At 01/27/2011 05:00 PM, Ken'ichi Ohmichi Write: > > > > Hi, > > > > When I tried to attach the interface after detaching the same interface, > > the virsh command output the following and it failed: > > > > # virsh detach-interface Domain01 network --mac 52:54:00:0d:78:92 > > Interface detached successfully > > > > # virsh attach-interface Domain01 network default --mac 52:54:00:0d:78:92 > > error: Failed to attach interface > > error: internal error unable to execute QEMU command 'device_add': > > Duplicate ID 'net0' for device > > # > > I can reproduce this problem. > > > > > The reason is that a detached device is not removed from the list > > "qemu_device_opts", and this patch fixes it. > > The detached device will be removed from the list "qemu_device_opts" > in qdev_free() asynchronously. 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. > > > > > > > Thanks > > Ken'ichi Ohmichi > > > > > > Signed-off-by: Ken'ichi Ohmichi > > --- > > --- a/hw/qdev.c 2011-01-27 17:42:25.0 +0900 > > +++ b/hw/qdev.c 2011-01-27 17:43:46.0 +0900 > > @@ -905,6 +905,8 @@ int do_device_del(Monitor *mon, const QD > > qerror_report(QERR_DEVICE_NOT_FOUND, id); > > return -1; > > } > > +qemu_opts_del(qemu_opts_find(&qemu_device_opts, id)); > > + > > We can not use qemu_device_opts here, because qemu_device_opts is > a static variable in qemu-config.c. We should use qemu_find_opts("device") > instead of qemu_device_opts. > > I test your patch by attach/detach interface, and qemu core dumps. > The reason may be that we call qemu_opts_del() twice. If qdev_free() is called asynchronously, I think qemu_opts_del() is called twice, too. And this patch isn't legal. I want to fix this problem, but I haven't understand about qemu-kvm, yet. X-( > > Here is the log(/var/log/libvirt/qemu/.log): > > *** glibc detected *** /usr/libexec/qemu-system-x86_64: free(): invalid > pointer: 0x0355f000 *** > === Backtrace: = > /lib64/libc.so.6[0x351f275676] > /usr/libexec/qemu-system-x86_64[0x43e2a6] > /usr/libexec/qemu-system-x86_64[0x43f9a0] > /usr/libexec/qemu-system-x86_64[0x4400ee] > /usr/libexec/qemu-system-x86_64[0x4cb176] > /usr/libexec/qemu-system-x86_64[0x5af9f6] > /usr/libexec/qemu-system-x86_64[0x4953c1] > /usr/libexec/qemu-system-x86_64[0x495dab] > /usr/libexec/qemu-system-x86_64[0x43a087] > /usr/libexec/qemu-system-x86_64[0x43a5dd] > /usr/libexec/qemu-system-x86_64[0x51f8f5] > /usr/libexec/qemu-system-x86_64[0x40ad4b] > /usr/libexec/qemu-system-x86_64[0x40ae52] > /usr/libexec/qemu-system-x86_64[0x585c81] > /usr/libexec/qemu-system-x86_64[0x589da7] > /lib64/libc.so.6(__libc_start_main+0xfd)[0x351f21ec5d] > /usr/libexec/qemu-system-x86_64[0x408a19] > === Memory map: > 0040-00784000 r-xp 08:06 679152 > /usr/libexec/qemu-system-x86_64 > 00983000-009c9000 rw-p 00383000 08:06 679152 > /usr/libexec/qemu-system-x86_64 > 009c9000-01177000 rw-p 00:00 0 > 01177000-01178000 rwxp 00:00 0 > 01178000-011d5000 rw-p 00:00 0 > 02d32000-03109000 rw-p 00:00 0 > 03109000-03119000 rw-p 00:00 0 > 03119000-03134000 rw-p 00:00 0 > 03134000-03144000 rw-p 00:00 0 > 03144000-0352c000 rw-p 00:00 0 > 0352c000-0353c000 rw-p 00:00 0 > 0353c000-0354f000 rw-p 00:00 0 > 0354f000-0355f000 rw-p 00:00 0 > 0355f000-0358 rw-p 00:00 0 > 4154f000-4954f000 rwxp 00:00 0 > 328d00-328d038000 r-xp 08:06 394303 > /lib64/libgssapi_krb5.so.2.2 > 328d038000-328d237000 ---p 00038000 08:06 394303 > /lib64/libgssapi_krb5.so.2.2 > 328d237000-328d239000 rw-p 00037000 08:06 394303 > /lib64/libgssapi_krb5.so.2.2 > 328d40-328d453000 r-xp 08:06 685072 > /usr/lib64/libssl.so.1.0.0 > 328d453000-328d653000 ---p 00053000 08:06 685072 > /usr/lib64/libssl.so.1.0.0 > 328d653000-328d65b000 rw-p 00053000 08:06 685072 > /usr/lib64/libssl.so.1.0.0 > 328d80-328d827000 r-xp 08:06 394300 > /lib64/libk5crypto.so.3.1 > 328d827000-328da27000 ---p 00027000 08:06 394300 > /lib64/libk5crypto.so.3.1 > 328da27000-328da29000 rw-p 00027000 08:06 394300
Re: [Qemu-devel] [PATCH] Remove a detached device from qemu_device_opts.
Hi Minoru, On Tue, Feb 15, 2011 at 3:32 AM, Minoru Usui 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 Regards, -- William
Re: [Qemu-devel] [PATCH] Remove a detached device from qemu_device_opts.
Hi, William, Markus and other people. On Wed, 23 Feb 2011 10:42:02 +0100 William Dauchy wrote: > Hi Minoru, > > On Tue, Feb 15, 2011 at 3:32 AM, Minoru Usui 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
Re: [Qemu-devel] [PATCH] Remove a detached device from qemu_device_opts.
Minoru Usui writes: > Hi, William, Markus and other people. > > On Wed, 23 Feb 2011 10:42:02 +0100 > William Dauchy wrote: > >> Hi Minoru, >> >> On Tue, Feb 15, 2011 at 3:32 AM, Minoru Usui 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.