iommu.lists.linux-foundation.org archive mirror
 help / color / mirror / Atom feed
* [PATCH] x86/pci: Some buggy virtual functions incorrectly report 1 for intx.
@ 2018-07-16 20:42 Ashok Raj
  2018-07-16 21:17 ` Alex Williamson
  0 siblings, 1 reply; 3+ messages in thread
From: Ashok Raj @ 2018-07-16 20:42 UTC (permalink / raw)
  To: Alex Williamson, iommu
  Cc: Ashok Raj, linux-kernel, stable, Joerg Roedel, Bjorn Helgaas,
	Gage Eads

PCI_INTERRUPT_PIN should always read  0 for SRIOV Virtual Functions.

Some SRIOV devices have some bugs in RTL and VF's end up reading 1
instead of 0 for the PIN.

We could enforce it by default in vfio_pci_nointx.

Reported-by: Gage Eads <gage.eads@intel.com>
Tested-by: Gage Eads <gage.eads@intel.com>
Signed-off-by: Ashok Raj <ashok.raj@intel.com>
Cc: linux-kernel@vger.kernel.org
Cc: stable@vger.kernel.org
Cc: iommu@lists.linux-foundation.org
Cc: Joerg Roedel <joro@8bytes.org>
Cc: Bjorn Helgaas <helgaas@kernel.org>
Cc: Gage Eads <gage.eads@intel.com>
---
 drivers/vfio/pci/vfio_pci.c | 7 +++++++
 1 file changed, 7 insertions(+)

diff --git a/drivers/vfio/pci/vfio_pci.c b/drivers/vfio/pci/vfio_pci.c
index b423a30..bc3f4fa 100644
--- a/drivers/vfio/pci/vfio_pci.c
+++ b/drivers/vfio/pci/vfio_pci.c
@@ -192,6 +192,13 @@ static void vfio_pci_disable(struct vfio_pci_device *vdev);
  */
 static bool vfio_pci_nointx(struct pci_dev *pdev)
 {
+	/*
+	 * Per PCI, no VF's should have INTx
+	 * Simply disable it here
+	 */
+	if (pdev->is_virtfn)
+		return true;
+
 	switch (pdev->vendor) {
 	case PCI_VENDOR_ID_INTEL:
 		switch (pdev->device) {
-- 
2.7.4

^ permalink raw reply related	[flat|nested] 3+ messages in thread

* Re: [PATCH] x86/pci: Some buggy virtual functions incorrectly report 1 for intx.
  2018-07-16 20:42 [PATCH] x86/pci: Some buggy virtual functions incorrectly report 1 for intx Ashok Raj
@ 2018-07-16 21:17 ` Alex Williamson
  2018-07-16 22:13   ` Raj, Ashok
  0 siblings, 1 reply; 3+ messages in thread
From: Alex Williamson @ 2018-07-16 21:17 UTC (permalink / raw)
  To: Ashok Raj
  Cc: iommu, linux-kernel, stable, Joerg Roedel, Bjorn Helgaas,
	Gage Eads

On Mon, 16 Jul 2018 13:42:25 -0700
Ashok Raj <ashok.raj@intel.com> wrote:

> PCI_INTERRUPT_PIN should always read  0 for SRIOV Virtual Functions.
> 
> Some SRIOV devices have some bugs in RTL and VF's end up reading 1
> instead of 0 for the PIN.
> 
> We could enforce it by default in vfio_pci_nointx.
> 
> Reported-by: Gage Eads <gage.eads@intel.com>
> Tested-by: Gage Eads <gage.eads@intel.com>
> Signed-off-by: Ashok Raj <ashok.raj@intel.com>
> Cc: linux-kernel@vger.kernel.org
> Cc: stable@vger.kernel.org
> Cc: iommu@lists.linux-foundation.org
> Cc: Joerg Roedel <joro@8bytes.org>
> Cc: Bjorn Helgaas <helgaas@kernel.org>
> Cc: Gage Eads <gage.eads@intel.com>
> ---
>  drivers/vfio/pci/vfio_pci.c | 7 +++++++
>  1 file changed, 7 insertions(+)
> 
> diff --git a/drivers/vfio/pci/vfio_pci.c b/drivers/vfio/pci/vfio_pci.c
> index b423a30..bc3f4fa 100644
> --- a/drivers/vfio/pci/vfio_pci.c
> +++ b/drivers/vfio/pci/vfio_pci.c
> @@ -192,6 +192,13 @@ static void vfio_pci_disable(struct vfio_pci_device *vdev);
>   */
>  static bool vfio_pci_nointx(struct pci_dev *pdev)
>  {
> +	/*
> +	 * Per PCI, no VF's should have INTx
> +	 * Simply disable it here
> +	 */
> +	if (pdev->is_virtfn)
> +		return true;
> +
>  	switch (pdev->vendor) {
>  	case PCI_VENDOR_ID_INTEL:
>  		switch (pdev->device) {

Nak, this is not what vfio_pci_nointx() is meant for, it's been tried
before and it was broken:

https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/drivers/vfio/pci/vfio_pci.c?id=834814e80268c818f354c8f402e0c6604ed75589

This would cause *every* VF to print:

	dev_info(&pdev->dev, "Masking broken INTx support\n");

If the device is incapable of generating INTx then it's probably better
to drop it at vfio_pci_get_irq_count().  Please also note the subject is
misidentified, this is a "vfio/pci" patch, not an "x86/pci" patch.
kvm@vger is the official list for vfio patches.  Thanks,

Alex

^ permalink raw reply	[flat|nested] 3+ messages in thread

* Re: [PATCH] x86/pci: Some buggy virtual functions incorrectly report 1 for intx.
  2018-07-16 21:17 ` Alex Williamson
@ 2018-07-16 22:13   ` Raj, Ashok
  0 siblings, 0 replies; 3+ messages in thread
From: Raj, Ashok @ 2018-07-16 22:13 UTC (permalink / raw)
  To: Alex Williamson
  Cc: iommu, linux-kernel, stable, Joerg Roedel, Bjorn Helgaas,
	Gage Eads, Ashok Raj

Hi Alex

On Mon, Jul 16, 2018 at 03:17:57PM -0600, Alex Williamson wrote:
> >  static bool vfio_pci_nointx(struct pci_dev *pdev)
> >  {
> > +	/*
> > +	 * Per PCI, no VF's should have INTx
> > +	 * Simply disable it here
> > +	 */
> > +	if (pdev->is_virtfn)
> > +		return true;
> > +
> >  	switch (pdev->vendor) {
> >  	case PCI_VENDOR_ID_INTEL:
> >  		switch (pdev->device) {
> 
> Nak, this is not what vfio_pci_nointx() is meant for, it's been tried
> before and it was broken:

That seems to make sense. I'll spin a new patch and have that tested
before reposting with the following suggestions.

> 
> https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/drivers/vfio/pci/vfio_pci.c?id=834814e80268c818f354c8f402e0c6604ed75589
> 
> This would cause *every* VF to print:
> 
> 	dev_info(&pdev->dev, "Masking broken INTx support\n");
> 
> If the device is incapable of generating INTx then it's probably better
> to drop it at vfio_pci_get_irq_count().  Please also note the subject is
> misidentified, this is a "vfio/pci" patch, not an "x86/pci" patch.
> kvm@vger is the official list for vfio patches.  Thanks,
> 
> Alex

^ permalink raw reply	[flat|nested] 3+ messages in thread

end of thread, other threads:[~2018-07-16 22:13 UTC | newest]

Thread overview: 3+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2018-07-16 20:42 [PATCH] x86/pci: Some buggy virtual functions incorrectly report 1 for intx Ashok Raj
2018-07-16 21:17 ` Alex Williamson
2018-07-16 22:13   ` Raj, Ashok

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).