From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([208.118.235.92]:49645) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1SXiz6-0007Ln-41 for qemu-devel@nongnu.org; Thu, 24 May 2012 21:06:29 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1SXiz4-0005YH-4n for qemu-devel@nongnu.org; Thu, 24 May 2012 21:06:27 -0400 Received: from mail-pb0-f45.google.com ([209.85.160.45]:49081) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1SXiz3-0005Vu-Ug for qemu-devel@nongnu.org; Thu, 24 May 2012 21:06:26 -0400 Received: by pbbro12 with SMTP id ro12so1154816pbb.4 for ; Thu, 24 May 2012 18:06:23 -0700 (PDT) Message-ID: <4FBEDB06.8080901@ozlabs.ru> Date: Fri, 25 May 2012 11:06:14 +1000 From: Alexey Kardashevskiy MIME-Version: 1.0 References: <4FBDE6D6.80700@ozlabs.ru> <4FBE2349.6040800@siemens.com> <1337870494.4714.1.camel@ul30vt> In-Reply-To: <1337870494.4714.1.camel@ul30vt> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Subject: Re: [Qemu-devel] [RFC PATCH] PCI: Introduce INTx check & mask API List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Alex Williamson Cc: kvm@vger.kernel.org, Jan Kiszka , qemu-devel@nongnu.org, Alex Graf , David Gibson On 25/05/12 00:41, Alex Williamson wrote: >>> [Found while debugging VFIO on POWER but it is platform independent] >>> >>> There is a feature in PCI (>=2.3?) to mask/unmask INTx via PCI_COMMAND and >>> PCI_STATUS registers. >> >> Yes, 2.3 introduced this. Masking is done via command register, checking >> if the source was the PCI in question via the status register. The >> latter is important for supporting IRQ sharing - and that's why we >> introduced this masking API to the PCI layer. >>> And there is some API to support that (commit a2e27787f893621c5a6b865acf6b7766f8671328). >>> >>> I have a network adapter: >>> 0001:00:01.0 Ethernet controller: Chelsio Communications Inc T310 10GbE Single Port Adapter >>> Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr+ Stepping- SERR+ FastB2B- DisINTx- >>> Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- SERR- >> >>> pci_intx_mask_supported() reports that the feature is supported for this adapter >>> BUT the adapter does not set PCI_STATUS_INTERRUPT so pci_check_and_set_intx_mask() >>> never changes PCI_COMMAND and INTx does not work on it when we use it as VFIO-PCI device. >>> >>> If I remove the check of this bit, it works fine as it is called from an interrupt handler and >>> Status bit check is redundant. >>> >>> Opened a spec: >>> PCI LOCAL BUS SPECIFICATION, REV. 3.0, Table 6-2: Status Register Bits >>> === >>> 3 This read-only bit reflects the state of the interrupt in the >>> device/function. Only when the Interrupt Disable bit in the command >>> register is a 0 and this Interrupt Status bit is a 1, will the >>> device’s/function’s INTx# signal be asserted. Setting the Interrupt >>> Disable bit to a 1 has no effect on the state of this bit. >>> === >>> With this adapter, INTx# is asserted but Status bit is still 0. >>> >>> Is it mandatory for a device to set Status bit if it supports INTx masking? >>> >>> 2 Alex: if it is mandatory, then we need to be able to disable pci_2_3 in VFIO-PCI >>> somehow. >> >> Since PCI 2.3, this bit is mandatory, and it should be independent of >> the masking bit. The question is, if your device is supposed to support >> 2.3, thus is just buggy, or if our detection algorithm is unreliable. It >> basically builds on the assumption that, if we can flip the mask bit, >> the feature should be present. I guess that is the best we can do. Maybe >> we can augment this with a blacklist of devices that "support" flipping >> without actually providing the feature. > > Yep, that's what I'd suggest as well, add a blacklist to > pci_intx_mask_supported() so this device returns false and we require an > exclusive interrupt for it. Thanks, Okay, here is one for the starter: aik@vpl2:~$ lspci -s 1:1:0.0 0001:01:00.0 Ethernet controller: Chelsio Communications Inc T310 10GbE Single Port Adapter aik@vpl2:~$ lspci -ns 1:1:0.0 0001:01:00.0 0200: 1425:0030 -- Alexey