Re: [PATCH 0/3] PCI: Rework config space locking, add INTx masking services
On 2011-10-14 16:48, Jan Kiszka wrote: On 2011-10-06 17:48, Jesse Barnes wrote: On Mon, 12 Sep 2011 18:54:01 +0200 Jan Kiszka jan.kis...@siemens.com wrote: This series tries to heal the currently broken locking scheme around PCI config space accesses. We have an interface lock out access via sysfs, but that service wrongly assumes it is only called by one instance at a time for some device. So two loops doing echo 1 /sys/bus/pci/devices/some-device/reset in parallel will trigger a kernel BUG at the moment. Besides synchronizing with user space, we also need to manage config space access of generic PCI drivers. They need to mask legacy interrupt lines while the specific driver runs in user space or a guest OS. The approach taken here is provide mutex-like locking for general access - which still requires a special mechanism due to requirements of the IBM Power RAID SCSI driver. Furthermore, INTx masking is now available via the PCI core and synchronized via the internal pci_lock. Not sure who may want to take this, so I'm CC'ing broadly. ISTR a bunch of discussion about this (just back from lots of work travel and vacation, sorry I missed most of it). Is this the agreed upon way of handling it? If so, can I get some Reviewed/Acked-bys from people? I hope this is acceptable. These changes are required for further improvements of the KVM device assignment support (INTx sharing). So I would appreciate any ack or whatever feedback as well. At least two acks arrived by now. But I guess this series is not yet lined up for the 3.2 window, is it? Can we get it merged for 3.3? Just let me know if any rebasing is required and against which tree. Thanks, Jan -- Siemens AG, Corporate Technology, CT T DE IT 1 Corporate Competence Center Embedded Linux -- To unsubscribe from this list: send the line unsubscribe kvm in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 0/3] PCI: Rework config space locking, add INTx masking services
On Mon, Sep 12, 2011 at 06:54:01PM +0200, Jan Kiszka wrote: This series tries to heal the currently broken locking scheme around PCI config space accesses. We have an interface lock out access via sysfs, but that service wrongly assumes it is only called by one instance at a time for some device. So two loops doing echo 1 /sys/bus/pci/devices/some-device/reset in parallel will trigger a kernel BUG at the moment. Besides synchronizing with user space, we also need to manage config space access of generic PCI drivers. They need to mask legacy interrupt lines while the specific driver runs in user space or a guest OS. The approach taken here is provide mutex-like locking for general access - which still requires a special mechanism due to requirements of the IBM Power RAID SCSI driver. Furthermore, INTx masking is now available via the PCI core and synchronized via the internal pci_lock. Not sure who may want to take this, so I'm CC'ing broadly. CC: Brian King brk...@linux.vnet.ibm.com Jan Kiszka (3): pci: Rework config space blocking services pci: Introduce INTx check mask API uio: Convert uio_generic_pci to new intx masking API For the series: Acked-by: Michael S. Tsirkin m...@redhat.com drivers/pci/access.c | 76 +-- drivers/pci/iov.c | 12 ++-- drivers/pci/pci.c | 114 - drivers/pci/pci.h |2 + drivers/scsi/ipr.c| 66 +--- drivers/scsi/ipr.h|1 + drivers/uio/uio_pci_generic.c | 82 +++--- include/linux/pci.h | 17 -- 8 files changed, 248 insertions(+), 122 deletions(-) -- 1.7.3.4 -- To unsubscribe from this list: send the line unsubscribe kvm in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 0/3] PCI: Rework config space locking, add INTx masking services
On 2011-10-06 17:48, Jesse Barnes wrote: On Mon, 12 Sep 2011 18:54:01 +0200 Jan Kiszka jan.kis...@siemens.com wrote: This series tries to heal the currently broken locking scheme around PCI config space accesses. We have an interface lock out access via sysfs, but that service wrongly assumes it is only called by one instance at a time for some device. So two loops doing echo 1 /sys/bus/pci/devices/some-device/reset in parallel will trigger a kernel BUG at the moment. Besides synchronizing with user space, we also need to manage config space access of generic PCI drivers. They need to mask legacy interrupt lines while the specific driver runs in user space or a guest OS. The approach taken here is provide mutex-like locking for general access - which still requires a special mechanism due to requirements of the IBM Power RAID SCSI driver. Furthermore, INTx masking is now available via the PCI core and synchronized via the internal pci_lock. Not sure who may want to take this, so I'm CC'ing broadly. ISTR a bunch of discussion about this (just back from lots of work travel and vacation, sorry I missed most of it). Is this the agreed upon way of handling it? If so, can I get some Reviewed/Acked-bys from people? I hope this is acceptable. These changes are required for further improvements of the KVM device assignment support (INTx sharing). So I would appreciate any ack or whatever feedback as well. Thanks, Jan -- Siemens AG, Corporate Technology, CT T DE IT 1 Corporate Competence Center Embedded Linux -- To unsubscribe from this list: send the line unsubscribe kvm in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 0/3] PCI: Rework config space locking, add INTx masking services
On 10/06/2011 10:48 AM, Jesse Barnes wrote: On Mon, 12 Sep 2011 18:54:01 +0200 Jan Kiszka jan.kis...@siemens.com wrote: This series tries to heal the currently broken locking scheme around PCI config space accesses. We have an interface lock out access via sysfs, but that service wrongly assumes it is only called by one instance at a time for some device. So two loops doing echo 1 /sys/bus/pci/devices/some-device/reset in parallel will trigger a kernel BUG at the moment. Besides synchronizing with user space, we also need to manage config space access of generic PCI drivers. They need to mask legacy interrupt lines while the specific driver runs in user space or a guest OS. The approach taken here is provide mutex-like locking for general access - which still requires a special mechanism due to requirements of the IBM Power RAID SCSI driver. Furthermore, INTx masking is now available via the PCI core and synchronized via the internal pci_lock. Not sure who may want to take this, so I'm CC'ing broadly. ISTR a bunch of discussion about this (just back from lots of work travel and vacation, sorry I missed most of it). Is this the agreed upon way of handling it? If so, can I get some Reviewed/Acked-bys from people? Acked-by: Brian King brk...@linux.vnet.ibm.com -- Brian King Linux on Power Virtualization IBM Linux Technology Center -- To unsubscribe from this list: send the line unsubscribe kvm in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 0/3] PCI: Rework config space locking, add INTx masking services
On Mon, 12 Sep 2011 18:54:01 +0200 Jan Kiszka jan.kis...@siemens.com wrote: This series tries to heal the currently broken locking scheme around PCI config space accesses. We have an interface lock out access via sysfs, but that service wrongly assumes it is only called by one instance at a time for some device. So two loops doing echo 1 /sys/bus/pci/devices/some-device/reset in parallel will trigger a kernel BUG at the moment. Besides synchronizing with user space, we also need to manage config space access of generic PCI drivers. They need to mask legacy interrupt lines while the specific driver runs in user space or a guest OS. The approach taken here is provide mutex-like locking for general access - which still requires a special mechanism due to requirements of the IBM Power RAID SCSI driver. Furthermore, INTx masking is now available via the PCI core and synchronized via the internal pci_lock. Not sure who may want to take this, so I'm CC'ing broadly. ISTR a bunch of discussion about this (just back from lots of work travel and vacation, sorry I missed most of it). Is this the agreed upon way of handling it? If so, can I get some Reviewed/Acked-bys from people? Thanks, -- Jesse Barnes, Intel Open Source Technology Center signature.asc Description: PGP signature
[PATCH 0/3] PCI: Rework config space locking, add INTx masking services
This series tries to heal the currently broken locking scheme around PCI config space accesses. We have an interface lock out access via sysfs, but that service wrongly assumes it is only called by one instance at a time for some device. So two loops doing echo 1 /sys/bus/pci/devices/some-device/reset in parallel will trigger a kernel BUG at the moment. Besides synchronizing with user space, we also need to manage config space access of generic PCI drivers. They need to mask legacy interrupt lines while the specific driver runs in user space or a guest OS. The approach taken here is provide mutex-like locking for general access - which still requires a special mechanism due to requirements of the IBM Power RAID SCSI driver. Furthermore, INTx masking is now available via the PCI core and synchronized via the internal pci_lock. Not sure who may want to take this, so I'm CC'ing broadly. CC: Brian King brk...@linux.vnet.ibm.com Jan Kiszka (3): pci: Rework config space blocking services pci: Introduce INTx check mask API uio: Convert uio_generic_pci to new intx masking API drivers/pci/access.c | 76 +-- drivers/pci/iov.c | 12 ++-- drivers/pci/pci.c | 114 - drivers/pci/pci.h |2 + drivers/scsi/ipr.c| 66 +--- drivers/scsi/ipr.h|1 + drivers/uio/uio_pci_generic.c | 82 +++--- include/linux/pci.h | 17 -- 8 files changed, 248 insertions(+), 122 deletions(-) -- 1.7.3.4 -- To unsubscribe from this list: send the line unsubscribe kvm in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
