[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Qemu-devel] [RFC PATCH] PCI: Introduce INTx check & mask API
From: |
Alex Williamson |
Subject: |
Re: [Qemu-devel] [RFC PATCH] PCI: Introduce INTx check & mask API |
Date: |
Thu, 24 May 2012 08:41:34 -0600 |
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]
> >
> > 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- <TAbort-
> > <MAbort- >SERR- <PERR- INTx-
> >
> > 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,
Alex
- [Qemu-devel] [RFC PATCH] PCI: Introduce INTx check & mask API, Alexey Kardashevskiy, 2012/05/24
- Re: [Qemu-devel] [RFC PATCH] PCI: Introduce INTx check & mask API, Jan Kiszka, 2012/05/24
- Re: [Qemu-devel] [RFC PATCH] PCI: Introduce INTx check & mask API,
Alex Williamson <=
- Re: [Qemu-devel] [RFC PATCH] PCI: Introduce INTx check & mask API, Alexey Kardashevskiy, 2012/05/24
- Re: [Qemu-devel] [RFC PATCH] PCI: Introduce INTx check & mask API, Jan Kiszka, 2012/05/24
- Re: [Qemu-devel] [RFC PATCH] PCI: Introduce INTx check & mask API, Alexey Kardashevskiy, 2012/05/24
- Re: [Qemu-devel] [RFC PATCH] PCI: Introduce INTx check & mask API, Jan Kiszka, 2012/05/25
- Re: [Qemu-devel] [RFC PATCH] PCI: Introduce INTx check & mask API, Alexey Kardashevskiy, 2012/05/25
- Re: [Qemu-devel] [RFC PATCH] PCI: Introduce INTx check & mask API, Jan Kiszka, 2012/05/25