Re: [Qemu-devel] [PATCH] `qdev_free` when unplug a pci device

[Ryan Harper <ryanh@us.ibm.com>]

* Wen Congyang <wency@cn.fujitsu.com> [2011-03-08 23:09]:
> At 03/09/2011 12:08 PM, Ryan Harper Write:
> > * Wen Congyang <wency@cn.fujitsu.com> [2011-02-27 20:56]:
> >> Hi Markus Armbruster
> >>
> >> At 02/23/2011 04:30 PM, Markus Armbruster Write:
> >>> Isaku Yamahata <yamahata@valinux.co.jp> writes:
> >>>
> >>
> >> <snip>
> >>
> >>>
> >>> 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