public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Bjorn Helgaas <helgaas@kernel.org>
To: sathyanarayanan kuppuswamy  <sathyanarayanan.kuppuswamy@linux.intel.com>
Cc: "Raj, Ashok" <ashok.raj@intel.com>,
	corbet@lwn.net, linux-doc@vger.kernel.org,
	linux-kernel@vger.kernel.org, linux-pci@vger.kernel.org,
	Keith Busch <keith.busch@intel.com>,
	alex.williamson@redhat.com
Subject: Re: [PATCH v1 1/5] PCI/IOV: Add support to verify PF/VF spec compliance
Date: Tue, 23 Apr 2019 17:11:34 -0500	[thread overview]
Message-ID: <20190423221134.GI14616@google.com> (raw)
In-Reply-To: <22ad30c0-fc7e-b5ac-a224-c1a247c33359@linux.intel.com>

On Fri, Apr 19, 2019 at 11:41:31AM -0700, sathyanarayanan kuppuswamy wrote:
> On 4/19/19 10:37 AM, Raj, Ashok wrote:
> > On Fri, Apr 19, 2019 at 08:59:18AM -0500, Bjorn Helgaas wrote:
> > > On Wed, Mar 06, 2019 at 02:11:14PM -0800, sathyanarayanan.kuppuswamy@linux.intel.com wrote:
> > > > From: Kuppuswamy Sathyanarayanan <sathyanarayanan.kuppuswamy@linux.intel.com>
> > > > 
> > > > PF/VF implementation must comply with PCIe specification as
> > > > defined in r4.0, sec 9.3.4, 9.3.5, 9.3.6 and 9.3.7. And if
> > > > it does not comply, return error and skip PF/VF device
> > > > creation.
> > > As far as I can tell, this patch basically looks for excuses not to
> > > enable SR-IOV.  Does this actually solve a problem?  Are there
> > > non-compliant devices out there that blow up if we enable SR-IOV?
> > We ran into one case with a future product for INTx value on VF's. We do have
> > a quirk for it upstream now. We thought it might be good to just run through
> > some of the basic requirements and see if any device violates it, that would allow
> > us to catch them early.
> > 
> > We are looking into other things like PASID and End-2-End prefix capability for instance.
> > There is another subtle thing like number of eetlp_prefix_supported. Which i don't
> > pci core checks today, and we might need to do that to be compliant or find devices
> > that break that contract.
> > 
> > Real intend is to be find such breaks early, it also helps the product guys :-)
> > 
> > With upcoming vIOMMU effort, we need to ensure that capabilities are exported properly
> > depending on if its a SRIOV-PF/VF or a Scalable device.
> > 
> > Cheers,
> > Ashok
> 
> I agree with Ashok's comments. It helps us find SRIOV related features
> enable/disable issues easily.
> 
> Also, there is some of level of spec compliance checks in enabling
> PASID/PRI/ATS already in our existing code.
> 
> I am just grouping them together in one place and expanded it for other IOV
> related features.

My $0.02:

  - If there's a problem that actually prevents Linux from using a feature,
    check for the problem close to the point where we use the feature.

  - If you want to check for spec compliance, most of that can be done more
    easily in user-space by examining lspci output.

Bjorn

  reply	other threads:[~2019-04-23 22:11 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <cover.1551909341.git.sathyanarayanan.kuppuswamy@linux.intel.com>
2019-03-06 22:11 ` [PATCH v1 1/5] PCI/IOV: Add support to verify PF/VF spec compliance sathyanarayanan.kuppuswamy
2019-04-19 13:59   ` Bjorn Helgaas
2019-04-19 17:37     ` Raj, Ashok
2019-04-19 18:41       ` sathyanarayanan kuppuswamy
2019-04-23 22:11         ` Bjorn Helgaas [this message]
2019-04-23 22:57           ` Raj, Ashok
2019-03-06 22:11 ` [PATCH v1 2/5] PCI/ATS: Fix PRI PF/VF dependency issues sathyanarayanan.kuppuswamy
2019-03-06 22:11 ` [PATCH v1 3/5] PCI/ATS: Fix PASID " sathyanarayanan.kuppuswamy
2019-03-06 22:11 ` [PATCH v1 4/5] PCI/ATS: For PF/VF skip ATS initalization if spec check failed sathyanarayanan.kuppuswamy
2019-03-06 22:11 ` [PATCH v1 5/5] PCI/ATS: Fix ATS PF/VF dependency issues sathyanarayanan.kuppuswamy

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20190423221134.GI14616@google.com \
    --to=helgaas@kernel.org \
    --cc=alex.williamson@redhat.com \
    --cc=ashok.raj@intel.com \
    --cc=corbet@lwn.net \
    --cc=keith.busch@intel.com \
    --cc=linux-doc@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-pci@vger.kernel.org \
    --cc=sathyanarayanan.kuppuswamy@linux.intel.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox