From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from [140.186.70.92] (port=44283 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1PxCdT-0001Hw-I4 for qemu-devel@nongnu.org; Wed, 09 Mar 2011 01:12:40 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1PxCdS-00069J-6Q for qemu-devel@nongnu.org; Wed, 09 Mar 2011 01:12:39 -0500 Received: from e4.ny.us.ibm.com ([32.97.182.144]:35570) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1PxCdS-00068y-3h for qemu-devel@nongnu.org; Wed, 09 Mar 2011 01:12:38 -0500 Received: from d01dlp02.pok.ibm.com (d01dlp02.pok.ibm.com [9.56.224.85]) by e4.ny.us.ibm.com (8.14.4/8.13.1) with ESMTP id p295rMH3027445 for ; Wed, 9 Mar 2011 00:53:22 -0500 Received: from d01relay01.pok.ibm.com (d01relay01.pok.ibm.com [9.56.227.233]) by d01dlp02.pok.ibm.com (Postfix) with ESMTP id AEAFB6E8036 for ; Wed, 9 Mar 2011 01:12:35 -0500 (EST) Received: from d01av03.pok.ibm.com (d01av03.pok.ibm.com [9.56.224.217]) by d01relay01.pok.ibm.com (8.13.8/8.13.8/NCO v10.0) with ESMTP id p296CZM6385904 for ; Wed, 9 Mar 2011 01:12:35 -0500 Received: from d01av03.pok.ibm.com (loopback [127.0.0.1]) by d01av03.pok.ibm.com (8.14.4/8.13.1/NCO v10.0 AVout) with ESMTP id p296CZDO027612 for ; Wed, 9 Mar 2011 03:12:35 -0300 Date: Wed, 9 Mar 2011 00:12:30 -0600 From: Ryan Harper Subject: Re: [Qemu-devel] [PATCH] `qdev_free` when unplug a pci device Message-ID: <20110309061230.GP23238@us.ibm.com> References: <1298396180-23734-1-git-send-email-wdauchy@gmail.com> <20110223025001.GC19727@valinux.co.jp> <4D6B0DF8.5000407@cn.fujitsu.com> <20110309040814.GM23238@us.ibm.com> <4D770A51.6050509@cn.fujitsu.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4D770A51.6050509@cn.fujitsu.com> List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Wen Congyang Cc: qemu-devel@nongnu.org, Markus Armbruster , Isaku Yamahata , Ryan Harper , Gerd Hoffmann , William Dauchy * Wen Congyang [2011-03-08 23:09]: > At 03/09/2011 12:08 PM, Ryan Harper Write: > > * Wen Congyang [2011-02-27 20:56]: > >> Hi Markus Armbruster > >> > >> At 02/23/2011 04:30 PM, Markus Armbruster Write: > >>> Isaku Yamahata writes: > >>> > >> > >> > >> > >>> > >>> I don't think this patch is correct. Let me explain. > >>> > >>> Device hot unplug is *not* guaranteed to succeed. > >>> > >>> For some buses, such as USB, it always succeeds immediately, i.e. when > >>> the device_del monitor command finishes, the device is gone. Live is > >>> good. > >>> > >>> But for PCI, device_del merely initiates the ACPI unplug rain dance. It > >>> doesn't wait for the dance to complete. Why? The dance can take an > >>> unpredictable amount of time, including forever. > >>> > >>> Problem: Subsequent device_add can fail if it reuses the qdev ID or PCI > >>> slot, and the unplug has not yet completed (race condition), or it > >>> failed. Yes, Virginia, PCI hotplug *can* fail. > >>> > >>> When unplug succeeds, the qdev is automatically destroyed. > >>> pciej_write() does that for PIIX4. Looks like pcie_cap_slot_event() > >>> does it for PCIE. > >> > >> I got a similar problem. When I unplug a pci device by hand, it works > >> as expected, and I can hotplug it again. But when I use a srcipt to > >> do the same thing, sometimes it failed. I think I may find another bug. > >> > >> Steps to reproduce this bug: > >> 1. cat ./test-e1000.sh # RHEL6RC is domain name > >> #! /bin/bash > >> > >> while true; do > >> virsh attach-interface RHEL6RC network default --mac 52:54:00:1f:db:c7 --model e1000 > >> if [[ $? -ne 0 ]]; then > >> break > >> fi > >> virsh detach-interface RHEL6RC network --mac 52:54:00:1f:db:c7 > >> if [[ $? -ne 0 ]]; then > >> break > >> fi > >> sleep 5 > > > > How do you know that the guest has responded at this point before you > > attempt to attach again at the top of the loop. Any attach/detach > > requires the guest to respond to the request and it may not respond at > > all. > > When I attach/detach interface by hand, it works fine: I can see the new interface > when I attach it, and it disapears when I detached it. The point is that since the attach and detach require guest participation, this interface isn't reliable. You have a sleep 5 in your loop, hoping to wait long enough for the guest to respond, but after a number of iterations in your loop it fails, you can bump the sleep to to 3600 seconds and the guest *still* might not respond... -- Ryan Harper Software Engineer; Linux Technology Center IBM Corp., Austin, Tx ryanh@us.ibm.com