[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.
