All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Spassov, Stanislav" <stanspas@amazon.de>
To: "ashok.raj@intel.com" <ashok.raj@intel.com>,
	"okaya@kernel.org" <okaya@kernel.org>
Cc: "corbet@lwn.net" <corbet@lwn.net>,
	"alex.williamson@redhat.com" <alex.williamson@redhat.com>,
	"tglx@linutronix.de" <tglx@linutronix.de>,
	"akpm@linux-foundation.org" <akpm@linux-foundation.org>,
	"Schoenherr, Jan H." <jschoenh@amazon.de>,
	"rajatja@google.com" <rajatja@google.com>,
	"linux-pci@vger.kernel.org" <linux-pci@vger.kernel.org>,
	"bhelgaas@google.com" <bhelgaas@google.com>
Subject: Re: [PATCH v4 3/3] PCI: Add CRS handling to pci_dev_wait()
Date: Mon, 9 Mar 2020 16:38:46 +0000	[thread overview]
Message-ID: <af2ba4c11c28848dc7d1827c23e6b038cc051eed.camel@amazon.de> (raw)
In-Reply-To: <20200309161951.GA25817@otc-nc-03>

On Mon, 2020-03-09 at 09:19 -0700, Raj, Ashok wrote:
> On Mon, Mar 09, 2020 at 11:55:11AM -0400, Sinan Kaya wrote:
> > On 3/7/2020 12:20 PM, Stanislav Spassov wrote:
> > > +           rc = pci_dev_poll_until_not_equal(dev, PCI_VENDOR_ID, 0xffff,
> > > +                                             0x0001, reset_type, timeout,
> > > +                                             &waited, &id);
> > > +           if (rc)
> > > +                   return rc;
> > > +
> > 
> > If I remember right, this doesn't work for VF sending CRS because VF
> > always returns 0xffff for VENDOR_ID register.
> 
> Is this required by the PCIe spec? i think the only requirement is
> the 1s wait after PF has done the VF enable. See Implementation Note
> right above section 2.3.1.1 in the Base spec 5.0.
> 
> If this behavior is different for maybe a specific SRIOV device we should
> probably quirk the standard behavior?
> 
> The rules are mentioned in so many places, but looking through the
> SRIOV section's doesn't seem to specify special rules for VF's other than
> the wait time after VF enable.

PCI Express Base Specification Revision 5.0 Version 1.0 (May 22, 2019)
on pages 1139 and 1140 within section 9.3.4 PF/VF Configuration Space Header
describes:

"9.3.4.1.1 Vendor ID Register Changes (Offset 00h)
...
This field in all VFs returns FFFFh when read. VI software should return the Vendor ID value from the associated PF as the
Vendor ID value for the VF."

(and similar for the Device ID)

Right after that is an Implemention Note "Legacy PCI Probing Software" that explains:

"Returning FFFFh for Device ID and Vendor ID values allows some legacy software to ignore VFs."

So, whenever a VF is providing an actual response to a vid/did read, it will respond with a Successful Completion and the data
will be 0xFFFF. However, when the VF is not ready yet after a reset, I would expect it to be returning CRS completions just like
any other device (nothing in the spec explicitly confirms or denies this, as far as I can tell). Then, the root port has no idea
if a device that it received a CRS completion from is a PF or VF, so it has to treat them equivalently, and therefore (for CRS SV enabled)
synthesize 0x0001 for the VID.



Amazon Development Center Germany GmbH
Krausenstr. 38
10117 Berlin
Geschaeftsfuehrung: Christian Schlaeger, Jonathan Weiss
Eingetragen am Amtsgericht Charlottenburg unter HRB 149173 B
Sitz: Berlin
Ust-ID: DE 289 237 879



  reply	other threads:[~2020-03-09 16:38 UTC|newest]

Thread overview: 19+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-03-07 17:20 [PATCH v4 0/3] Improve PCI device post-reset readiness polling Stanislav Spassov
2020-03-07 17:20 ` [PATCH v4 1/3] PCI: Refactor polling loop out of pci_dev_wait Stanislav Spassov
2020-03-07 17:20 ` [PATCH v4 2/3] PCI: Cache CRS Software Visibiliy in struct pci_dev Stanislav Spassov
2021-09-12 13:32   ` Bjorn Helgaas
2021-09-13 16:06     ` Spassov, Stanislav
2020-03-07 17:20 ` [PATCH v4 3/3] PCI: Add CRS handling to pci_dev_wait() Stanislav Spassov
2020-03-09 15:55   ` Sinan Kaya
2020-03-09 16:19     ` Raj, Ashok
2020-03-09 16:38       ` Spassov, Stanislav [this message]
2020-03-09 17:33         ` Sinan Kaya
2021-09-11 14:03   ` Bjorn Helgaas
2021-09-13 16:29     ` Spassov, Stanislav
2021-09-13 16:38       ` Bjorn Helgaas
2021-09-13 18:04         ` Spassov, Stanislav
2021-09-14 17:53           ` Rajat Jain
2021-09-13 16:07   ` Bjorn Helgaas
2021-09-13 16:39     ` Spassov, Stanislav
2021-01-22  8:54 ` [PATCH v4 0/3] Improve PCI device post-reset readiness polling David Woodhouse
2021-09-10  9:32   ` David Woodhouse

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=af2ba4c11c28848dc7d1827c23e6b038cc051eed.camel@amazon.de \
    --to=stanspas@amazon.de \
    --cc=akpm@linux-foundation.org \
    --cc=alex.williamson@redhat.com \
    --cc=ashok.raj@intel.com \
    --cc=bhelgaas@google.com \
    --cc=corbet@lwn.net \
    --cc=jschoenh@amazon.de \
    --cc=linux-pci@vger.kernel.org \
    --cc=okaya@kernel.org \
    --cc=rajatja@google.com \
    --cc=tglx@linutronix.de \
    /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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.