From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([208.118.235.92]:33974) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1SXZEg-0001nJ-P9 for qemu-devel@nongnu.org; Thu, 24 May 2012 10:41:57 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1SXZEY-0005gQ-8N for qemu-devel@nongnu.org; Thu, 24 May 2012 10:41:54 -0400 Received: from mx1.redhat.com ([209.132.183.28]:3170) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1SXZEY-0005g1-08 for qemu-devel@nongnu.org; Thu, 24 May 2012 10:41:46 -0400 Message-ID: <1337870494.4714.1.camel@ul30vt> From: Alex Williamson Date: Thu, 24 May 2012 08:41:34 -0600 In-Reply-To: <4FBE2349.6040800@siemens.com> References: <4FBDE6D6.80700@ozlabs.ru> <4FBE2349.6040800@siemens.com> Content-Type: text/plain; charset="UTF-8" Mime-Version: 1.0 Content-Transfer-Encoding: quoted-printable 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: Jan Kiszka Cc: kvm@vger.kernel.org, Alexey Kardashevskiy , qemu-devel@nongnu.org, Alex Graf , David Gibson On Thu, 2012-05-24 at 09:02 -0300, Jan Kiszka wrote: > On 2012-05-24 04:44, Alexey Kardashevskiy wrote: > > [Found while debugging VFIO on POWER but it is platform independent] > >=20 > > There is a feature in PCI (>=3D2.3?) to mask/unmask INTx via PCI_COMM= AND and > > PCI_STATUS registers. >=20 > Yes, 2.3 introduced this. Masking is done via command register, checkin= g > 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. >=20 > >=20 > > And there is some API to support that (commit a2e27787f893621c5a6b865= acf6b7766f8671328). > >=20 > > I have a network adapter: > > 0001:00:01.0 Ethernet controller: Chelsio Communications Inc T310 10G= bE Single Port Adapter > > Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr+ = Stepping- SERR+ FastB2B- DisINTx- > > Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=3Dfast >TAbort- SERR- >=20 > > pci_intx_mask_supported() reports that the feature is supported for t= his adapter > > BUT the adapter does not set PCI_STATUS_INTERRUPT so pci_check_and_se= t_intx_mask() > > never changes PCI_COMMAND and INTx does not work on it when we use it= as VFIO-PCI device. > >=20 > > 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. > >=20 > > Opened a spec: > > PCI LOCAL BUS SPECIFICATION, REV. 3.0, Table 6-2: Status Register Bit= s > > =3D=3D=3D > > 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=E2=80=99s/function=E2=80=99s INTx# signal be asserted. Setting= the Interrupt > > Disable bit to a 1 has no effect on the state of this bit. > > =3D=3D=3D > > With this adapter, INTx# is asserted but Status bit is still 0. > >=20 > > Is it mandatory for a device to set Status bit if it supports INTx ma= sking? > >=20 > > 2 Alex: if it is mandatory, then we need to be able to disable pci_2_= 3 in VFIO-PCI > > somehow. >=20 > 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. I= t > 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. Mayb= e > 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, Alex