On 2011-08-25 21:07, Michael S. Tsirkin wrote:
> On Thu, Aug 25, 2011 at 08:52:08PM +0200, Jan Kiszka wrote:
>> On 2011-08-25 20:19, Michael S. Tsirkin wrote:
>>> On Thu, Aug 25, 2011 at 03:06:01PM +0200, Jan Kiszka wrote:
>>>>> I took a look at the sysfs triggered pci reset function and don't see any way
>>>>> that the controlling device driver ever gets to be involved in this reset.
>>>>> If code outside the ipr driver were to reset the adapter, the adapter firmware
>>>>> would be left in an uninitialized state and until scsi core starts timing
>>>>> out ops and driving EH, the card would be unusable. I can't imagine the
>>>>> ipr driver is unique in this.
>>>>
>>>> Right, that's why a PCI core service is needed for coordination.
>>>>
>>>> Jan
>>>
>>> But why do we want to trigger reset through sysfs while the
>>> driver runs?
>>
>> A perfectly valid race conditions are created by KVM and VFIO: shared
>> IRQ handler is triggered while the user space part wants to reset the
>> assigned device.
> 
> OK, that would be solved by blocking sysfs reset while
> config access is blocked, right?

...and VFIO's reset IOCTL. And any other potential pci_reset_function
caller. And you still need to synchronize those config space accesses
that don't wait for the block_ucfg_access while some reset is being
performed. This really screams for a redesign of config space locking.

Jan