From: Don Dutile <ddutile@redhat.com>
To: Ram Pai <linuxram@us.ibm.com>
Cc: Jesse Barnes <jbarnes@virtuousgeek.org>,
linux-pci@vger.kernel.org,
Benjamin Herrenschmidt <benh@kernel.crashing.org>,
Bjorn Helgaas <bhelgaas@google.com>,
Nishanth Aravamudan <nacc@us.ibm.com>,
prarit@redhat.com, brking@linux.vnet.ibm.com
Subject: Re: [RFC PATCH 1/1] PCI:delay configuration of SRIOV capability
Date: Tue, 06 Dec 2011 04:14:17 -0500 [thread overview]
Message-ID: <4EDDDCE9.7010600@redhat.com> (raw)
In-Reply-To: <20111206075143.GB31480@ram-ThinkPad-T61>
On 12/06/2011 02:51 AM, Ram Pai wrote:
> On Mon, Dec 05, 2011 at 04:25:02PM -0500, Don Dutile wrote:
>> On 12/05/2011 01:17 PM, Jesse Barnes wrote:
>>> On Sun, 6 Nov 2011 10:33:57 +0800
>>> Ram Pai<linuxram@us.ibm.com> wrote:
>>>
>>>> The SRIOV capability, namely page size and total_vfs of a device are
>>>> configured during enumeration phase of the device.
>>>> This can potentially interfere with the PCI operations of the platform,
>>>> if the IOV capability of the device is not enabled.
>>>>
>>>> The following patch postpones the configuration of the IOV capability of the
>>>> device to a later point, when the IOV capability is explicitly enabled
>>>> by the device driver.
>>>>
>>>> The patch is tested on x86 and power platform.
>>>>
>>>> Signed-off-by: Ram Pai<linuxram@us.ibm.com>
>>>> ---
>>>> drivers/pci/iov.c | 4 ++--
>>>> 1 files changed, 2 insertions(+), 2 deletions(-)
>>>>
>>>> diff --git a/drivers/pci/iov.c b/drivers/pci/iov.c
>>>> index b0446dd..c1a6f5c 100644
>>>> --- a/drivers/pci/iov.c
>>>> +++ b/drivers/pci/iov.c
>>>> @@ -346,6 +346,8 @@ static int sriov_enable(struct pci_dev *dev, int nr_virtfn)
>>>> return rc;
>>>> }
>>>>
>>>> + pci_write_config_dword(dev, iov->pos + PCI_SRIOV_SYS_PGSIZE, iov->pgsz);
>>>> +
>>>> iov->ctrl |= PCI_SRIOV_CTRL_VFE | PCI_SRIOV_CTRL_MSE;
>>>> pci_block_user_cfg_access(dev);
>>>> pci_write_config_word(dev, iov->pos + PCI_SRIOV_CTRL, iov->ctrl);
>>>> @@ -451,7 +453,6 @@ static int sriov_init(struct pci_dev *dev, int pos)
>>>>
>>>> found:
>>>> 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))
>>>> @@ -464,7 +465,6 @@ found:
>>>> return -EIO;
>>>>
>>>> pgsz&= ~(pgsz - 1);
>>>> - pci_write_config_dword(dev, pos + PCI_SRIOV_SYS_PGSIZE, pgsz);
>>>>
>>>> nres = 0;
>>>> for (i = 0; i< PCI_SRIOV_NUM_BARS; i++) {
>>>
>>> Anyone want to volunteer a tested-by for this one?
>>>
>>> Thanks,
>>
>> I tested this patch along with Ram's other recent patch for SRIOV:
>> [RFC PATCH 1/1]PCI: defer enablement of SRIOV BARS
>>
>> With or without this patch, device assignment to a KVM guest
>> using these patches worked for me. I used one PF in a quad-function
>> i350, configuring 2 VFs per i350. I did 4 assign/deassigns to make
>> sure multiple enable/disables worked.
>>
>> So, the patch doesn't correct any error I was seeing,
>> but it doesn't cause any regression either.
>
> Thanks Don for your tested-by.
>
> I recollect you had a issue, which I thought were not related or
> addressed by my patches. If I can get a dmesg of your machine, I probably will
> be able to see the relation.
>
> RP
>
My issue was more RHEL specific. Your patches appear to resolve the issues
in a more general manner, and one that saner (to me... delay SRIOV resource allocation
and setup until a driver is actually enabled with it, instead of always on no matter
what the system use of SRIOV is).
- Don
next prev parent reply other threads:[~2011-12-06 14:14 UTC|newest]
Thread overview: 21+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <20111006210320.GA14959@us.ibm.com>
[not found] ` <CAErSpo7b_6_AaZXW9XBx5p3-0PZJk-1jeCork__KePdzCS89OA@mail.gmail.com>
[not found] ` <1317970100.29415.305.camel@pasglop>
[not found] ` <CAErSpo58okGsDW4dOK4i0g_RUejkuQa=iw2uQ5HAJJZCwFtsbw@mail.gmail.com>
[not found] ` <20111007232516.GF2980@ram-ThinkPad-T61>
[not found] ` <1318057168.29415.333.camel@pasglop>
[not found] ` <20111008075353.GK2980@ram-ThinkPad-T61>
[not found] ` <1318060793.29415.347.camel@pasglop>
[not found] ` <20111102140325.004b9dad@jbarnes-desktop>
[not found] ` <20111103013014.GB393@ram-ThinkPad-T61>
[not found] ` <20111106023357.GB2383@ram-ThinkPad-T61>
2011-12-05 18:17 ` [RFC PATCH 1/1] PCI:delay configuration of SRIOV capability Jesse Barnes
2011-12-05 21:25 ` Don Dutile
2011-12-06 7:51 ` Ram Pai
2011-12-06 9:14 ` Don Dutile [this message]
2011-12-05 21:37 ` Jesse Barnes
[not found] ` <20111106023310.GA2383@ram-ThinkPad-T61>
2011-11-11 18:01 ` [RFC PATCH 1/1]PCI: defer enablement of SRIOV BARS Jesse Barnes
2011-11-14 4:33 ` Ram Pai
2011-11-14 4:56 ` Michael Wang
2011-12-05 18:32 ` Jesse Barnes
2011-12-07 8:22 ` Yinghai Lu
2011-12-07 9:25 ` Ram Pai
2011-12-07 19:33 ` Yinghai Lu
2011-12-07 20:23 ` Don Dutile
2011-12-07 20:35 ` Nishanth Aravamudan
2011-12-07 22:34 ` Don Dutile
2011-12-07 23:11 ` Yinghai Lu
2011-12-08 2:50 ` Ram Pai
2011-12-08 13:53 ` Jesse Barnes
2011-12-08 16:59 ` Yinghai Lu
2011-12-09 10:04 ` [PATCH 1/1 v2]PCI: " Ram Pai
2011-12-08 16:22 ` [RFC PATCH 1/1]PCI: " Don Dutile
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=4EDDDCE9.7010600@redhat.com \
--to=ddutile@redhat.com \
--cc=benh@kernel.crashing.org \
--cc=bhelgaas@google.com \
--cc=brking@linux.vnet.ibm.com \
--cc=jbarnes@virtuousgeek.org \
--cc=linux-pci@vger.kernel.org \
--cc=linuxram@us.ibm.com \
--cc=nacc@us.ibm.com \
--cc=prarit@redhat.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;
as well as URLs for NNTP newsgroup(s).