Hi Konrad,
I finally got some time to dig into why I had issues with the last patch. Added a lot of
printk:s to find out what happened. My conclusions, possibly incorrect, are as follows:
Each device bound to the pciback module will be reset twice during boot. The done-counter
in the completion struct will be set to 2 since no calls have been made to wait_for_completion.
The counter in the completion struct will be decremented to 1 at the first pcistub_get_pci_dev()
or pcistub_get_pci_dev_by_slot() call.
Something bad happens when pcistub_put_pci_dev() during shutdown of domU. It appears to me
as if the function is expected to block until reset is completed. Code from the patch file:
+ schedule_work(&found_psdev->reset_work);
+
+ /* Wait .. wait */
+ wait_for_completion(&found_psdev->reset_done);
+
The function will not wait since the done-counter is set to 1. The pcistub_put_pci_dev() will return
before the work item is excecuted. I do not belive that this was intended. The completion structs done
member is decremented to zero but once again set to 1 when the reset work item has been executed.
It is possible to boot the DomU a second time (done-counter in completion struct goes down to zero).
The problem is that pcistub_put_pci_dev() will leave the done-counter at zero when the domU is shut
down for the second time. Trying to boot the domU a third time will stall.
The get-functions expects to be able to decrement the completion counter without initiation work that
increments the counter and the put-function initiates the same number of reset works as the function
calls wait_for_completion(). It doesn't seem right. Could also explain why unbound devices hangs. Their
completion struct is not likely to be initiated with a count of 2 after startup.
Best Regards,
/Martin