public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Matthew Wilcox <matthew@wil.cx>
To: Andi Kleen <andi@firstfloor.org>
Cc: Yu Zhao <yu.zhao@intel.com>,
	jbarnes@virtuousgeek.org, linux-pci@vger.kernel.org,
	kvm@vger.kernel.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH v8 1/7] PCI: initialize and release SR-IOV capability
Date: Fri, 13 Feb 2009 10:49:59 -0700	[thread overview]
Message-ID: <20090213174958.GD16841@parisc-linux.org> (raw)
In-Reply-To: <877i3uwa0j.fsf@basil.nowhere.org>

On Fri, Feb 13, 2009 at 05:56:44PM +0100, Andi Kleen wrote:
> > +	pci_read_config_word(dev, pos + PCI_SRIOV_CTRL, &ctrl);
> > +	if (ctrl & PCI_SRIOV_CTRL_VFE) {
> > +		pci_write_config_word(dev, pos + PCI_SRIOV_CTRL, 0);
> > +		msleep(100);
> 
> That's really long. Hopefully that's really needed.

Yes and no.  The spec says:

  To allow components to perform internal initialization, system software
  must wait for at least 100 ms after changing the VF Enable bit from
  a 0 to a 1, before it is permitted to issue Configuration Requests to
  the VFs which are enabled by that VF Enable bit.

So we don't have to wait here, but we do have to wait before exposing
all these virtual functions to the rest of the system.  Should we add
more complexity, perhaps spawn a thread to do it asynchronously, or add
0.1 seconds to device initialisation?  A question without an easy
answer, iMO.

> > +
> > +	pci_write_config_word(dev, pos + PCI_SRIOV_CTRL, ctrl);
> > +	pci_write_config_word(dev, pos + PCI_SRIOV_NUM_VF, total);
> > +	pci_read_config_word(dev, pos + PCI_SRIOV_VF_OFFSET, &offset);
> > +	pci_read_config_word(dev, pos + PCI_SRIOV_VF_STRIDE, &stride);
> > +	if (!offset || (total > 1 && !stride))
> > +		return -EIO;
> > +
> > +	pci_read_config_dword(dev, pos + PCI_SRIOV_SUP_PGSIZE, &pgsz);
> > +	i = PAGE_SHIFT > 12 ? PAGE_SHIFT - 12 : 0;
> > +	pgsz &= ~((1 << i) - 1);
> > +	if (!pgsz)
> > +		return -EIO;
> 
> All the error paths don't seem to undo the config space writes.
> How will the devices behave with half initialized context?

I think we should clear the VF_ENABLE bit.  That action is also fraught
with danger:

  If software Clears VF Enable, software must allow 1 second after VF
  Enable is Cleared before reading any field in the SR-IOV Extended
  Capability or the VF Migration State Array (see Section 3.3.15.1).

Another msleep(1000) here?  Not pretty, but what else can we do?

Not to mention the danger of something else innocently using lspci -xxxx
to read a field in the extended capability -- I suspect we also need to
block user config accesses before clearing this bit.

-- 
Matthew Wilcox				Intel Open Source Technology Centre
"Bill, look, we understand that you're interested in selling us this
operating system, but compare it to ours.  We can't possibly take such
a retrograde step."

  parent reply	other threads:[~2009-02-13 17:50 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2009-02-10  8:59 [PATCH v8 0/7] PCI: Linux kernel SR-IOV support Yu Zhao
2009-02-10  8:59 ` [PATCH v8 1/7] PCI: initialize and release SR-IOV capability Yu Zhao
2009-02-13 16:56   ` Andi Kleen
2009-02-13 12:30     ` Yu Zhao
2009-02-13 17:49     ` Matthew Wilcox [this message]
2009-02-13 12:47       ` Yu Zhao
2009-02-10  8:59 ` [PATCH v8 2/7] PCI: restore saved SR-IOV state Yu Zhao
2009-02-10  8:59 ` [PATCH v8 3/7] PCI: reserve bus range for SR-IOV device Yu Zhao
2009-02-10  8:59 ` [PATCH v8 4/7] PCI: add SR-IOV API for Physical Function driver Yu Zhao
2009-02-10  8:59 ` [PATCH v8 5/7] PCI: handle SR-IOV Virtual Function Migration Yu Zhao
2009-02-10  8:59 ` [PATCH v8 6/7] PCI: document SR-IOV sysfs entries Yu Zhao
2009-02-10  8:59 ` [PATCH v8 7/7] PCI: manual for SR-IOV user and driver developer Yu Zhao

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=20090213174958.GD16841@parisc-linux.org \
    --to=matthew@wil.cx \
    --cc=andi@firstfloor.org \
    --cc=jbarnes@virtuousgeek.org \
    --cc=kvm@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-pci@vger.kernel.org \
    --cc=yu.zhao@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