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

[Wen Congyang]

At 03/09/2011 12:08 PM, Ryan Harper Write:
> * Wen Congyang <address@hidden> [2011-02-27 20:56]:
>> Hi Markus Armbruster
>>
>> At 02/23/2011 04:30 PM, Markus Armbruster Write:
>>> Isaku Yamahata <address@hidden> 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.


> 
>