This patchset enables EEH on SRIOV VFs. The general idea is to create proper
VF edev and VF PE and handle them properly.
Different from the Bus PE, VF PE just contain one VF. This introduces the
difference of EEH error handling on a VF PE. Generally, it has several
differences.
First, the VF's removal and re-enumerate rely on its PF. VF has a tight
relationship between its PF. This is not proper to enumerate a VF by usual
scan procedure. That's why virtfn_add/virtfn_remove are exported in this patch
set.
Second, the reset/restore of a VF is done in kernel space. FW is not aware of
the VF, this means the usual reset function done in FW will not work. One of
the patch will imitate the reset/restore function in kernel space.
Third, the VF may be removed during the PF's error_detected function. In this
case, the original error_detected->slot_reset->resume sequence is not proper
to those removed VFs, since they are re-created by PF in a fresh state. A flag
in eeh_dev is introduce to mark the eeh_dev is in error state. By doing so, we
track whether this device needs to be reset or not.
This has been tested both on host and in guest on Power8 with latest kernel
version.
v9:
* split pcibios_bus_add_device() into a separate patch
* Bjorn acked the PCI part and agreed this patch set to be merged from ppc
tree
* rebased on mpe/linux.git next branch
v8:
* fix on checking the return value of pnv_eeh_do_flr()
* introduced a weak function pcibios_bus_add_device() to create PE for VFs
v7:
* fix compile error when PCI_IOV is not set
v6:
* code / commit log refactor by Gavin
v5:
* remove the compound field, iterate on Master VF PE instead
* some code refine on PCI config restore and reset on VF
the wait time for assert and deassert
PCI device address format
check on edev->pcie_cap and edev->aer_cap before access them
v4:
* refine the change logs, comment and code style
* change pnv_pci_fixup_vf_eeh() to pnv_eeh_vf_final_fixup() and remove the
CONFIG_PCI_IOV macro
* reorder patch 5/6 to make the logic more reasonable
* remove remove_dev_pci_data()
* remove the EEH_DEV_VF flag, use edev->physfn to identify a VF EEH DEV and
remove related CONFIG_PCI_IOV macro
* add the option for VF reset
* fix the pnv_eeh_cfg_blocked() logic
* replace pnv_pci_cfg_{read,write} with eeh_ops->{read,write}_config in
pnv_eeh_vf_restore_config()
* rename pnv_eeh_vf_restore_config() to pnv_eeh_restore_vf_config()
* rename pnv_pci_fixup_vf_caps() to pnv_pci_vf_header_fixup() and move it
to arch/powerpc/platforms/powernv/pci.c
* add a field compound in pnv_ioda_pe to link compound PEs
* handle compound PE for VF PEs
v3:
* add back vf_index in pci_dn to track the VF's index
* rename ppdev in eeh_dev to physfn for consistency
* move edev->physfn assignment before dev->dev.archdata.edev is set
* move pnv_pci_fixup_vf_eeh() and pnv_pci_fixup_vf_caps() to eeh-powernv.c
* more clear and detail in commit log and comment in code
* merge eeh_rmv_virt_device() with eeh_rmv_device()
* move the cfg_blocked check logic from pnv_eeh_read/write_config() to
pnv_eeh_cfg_blocked()
* move the vf reset/restore logic into its own patch, two patches are
created.
powerpc/powernv: Support PCI config restore for VFs
powerpc/powernv: Support EEH reset for VFs
* simplify the vf reset logic
v2:
* add prefix pci_iov_ to virtfn_add/virtfn_remove
* use EEH_DEV_VF as a flag for a VF's eeh_dev
* use eeh_dev instead of edev in change log
* remove vf_index in eeh_dev, calculate it from pdn->busno and devfn
* do eeh_add_device_late() and eeh_sysfs_add_device() both after pci_dev is
well initialized
* do FLR to reset a VF PE
* imitate the restore function in FW for VF
* remove the reverse order patch, since it is still under discussion
Wei Yang (11):
PCI/IOV: Rename and export virtfn_add/virtfn_remove
PCI: Add pcibios_bus_add_device() weak function
powerpc/pci: Cache VF index in pci_dn
powerpc/pci: Remove VFs prior to PF
powerpc/eeh: Cache only BARs, not windows or IOV BARs
powerpc/powernv: EEH device for VF
powerpc/eeh: Create PE for VFs
powerpc/powernv: Support EEH reset for VF PE
powerpc/powernv: Support PCI config restore for VFs
powerpc/eeh: Support error recovery for VF PE
powerpc/powernv: compound PE for VFs
arch/powerpc/include/asm/eeh.h | 4 +
arch/powerpc/include/asm/pci-bridge.h | 2 +
arch/powerpc/kernel/eeh.c | 8 +
arch/powerpc/kernel/eeh_cache.c | 6 +-
arch/powerpc/kernel/eeh_driver.c | 100 +++++++++---
arch/powerpc/kernel/eeh_pe.c | 13 +-
arch/powerpc/kernel/pci-hotplug.c | 2 +-
arch/powerpc/kernel/pci_dn.c | 16 +-
arch/powerpc/platforms/powernv/eeh-powernv.c | 220 +++++++++++++++++++++++++-
arch/powerpc/platforms/powernv/pci-ioda.c | 46 +++++-
arch/powerpc/platforms/powernv/pci.c | 35 +++-
drivers/pci/bus.c | 3 +
drivers/pci/iov.c | 10 +-
include/linux/pci.h | 8 +
14 files changed, 428 insertions(+), 45 deletions(-)
--
1.7.9.5
This patch adds a weak function pcibios_bus_add_device() for arch dependent
code could do proper setup. For example, powerpc could setup EEH related
resources.
Signed-off-by: Wei Yang <redacted>
Acked-by: Bjorn Helgaas <bhelgaas@google.com>
---
drivers/pci/bus.c | 3 +++
1 file changed, 3 insertions(+)
During EEH recovery, hotplug is applied to the devices which don't
have drivers or their drivers don't support EEH. However, the hotplug,
which was implemented based on PCI bus, can't be applied to VF directly.
The patch renames virtn_{add,remove}() and exports them so that they
can be used in PCI hotplug during EEH recovery.
[gwshan: changelog]
Signed-off-by: Wei Yang <redacted>
Reviewed-by: Gavin Shan <redacted>
Acked-by: Bjorn Helgaas <bhelgaas@google.com>
---
drivers/pci/iov.c | 10 +++++-----
include/linux/pci.h | 8 ++++++++
2 files changed, 13 insertions(+), 5 deletions(-)
@@ -1668,6 +1668,8 @@ int pci_iov_virtfn_devfn(struct pci_dev *dev, int id);intpci_enable_sriov(structpci_dev*dev,intnr_virtfn);voidpci_disable_sriov(structpci_dev*dev);+intpci_iov_virtfn_add(structpci_dev*dev,intid,intreset);+voidpci_iov_virtfn_remove(structpci_dev*dev,intid,intreset);intpci_num_vf(structpci_dev*dev);intpci_vfs_assigned(structpci_dev*dev);intpci_sriov_set_totalvfs(structpci_dev*dev,u16numvfs);
@@ -1685,6 +1687,12 @@ static inline int pci_iov_virtfn_devfn(struct pci_dev *dev, int id)staticinlineintpci_enable_sriov(structpci_dev*dev,intnr_virtfn){return-ENODEV;}staticinlinevoidpci_disable_sriov(structpci_dev*dev){}+staticinlineintpci_iov_virtfn_add(structpci_dev*dev,intid,intreset)+{+return-ENOSYS;+}+staticinlinevoidpci_iov_virtfn_remove(structpci_dev*dev,intid,intreset)+{}staticinlineintpci_num_vf(structpci_dev*dev){return0;}staticinlineintpci_vfs_assigned(structpci_dev*dev){return0;}
The patch caches the VF index in pci_dn, which can be used to calculate
VF's bus, device and function number. Those information helps to locate
the VF's PCI device instance when doing hotplug during EEH recovery if
necessary.
Signed-off-by: Wei Yang <redacted>
Acked-by: Gavin Shan <redacted>
---
arch/powerpc/include/asm/pci-bridge.h | 1 +
arch/powerpc/kernel/pci_dn.c | 4 +++-
2 files changed, 4 insertions(+), 1 deletion(-)
@@ -210,6 +210,7 @@ struct pci_dn {#define IODA_INVALID_PE (-1)#ifdef CONFIG_PPC_POWERNVintpe_number;+intvf_index;/* VF index in the PF */#ifdef CONFIG_PCI_IOVu16vfs_expanded;/* number of VFs IOV BAR expanded */u16num_vfs;/* number of VFs enabled*/
EEH address cache, which helps to locate the PCI device according to
the given (physical) MMIO address, didn't cover PCI bridges. Also, it
shouldn't return PF with address in PF's IOV BARs. Instead, the VFs
should be returned.
Also, by doing so, it removes the type check in
eeh_addr_cache_insert_dev(), since bridge's window would not be cached.
The patch restricts the address cache to cover first 7 BARs for the
above purposes.
[gwshan: changelog]
Signed-off-by: Wei Yang <redacted>
Acked-by: Gavin Shan <redacted>
---
arch/powerpc/kernel/eeh_cache.c | 6 +-----
1 file changed, 1 insertion(+), 5 deletions(-)
@@ -196,7 +196,7 @@ static void __eeh_addr_cache_insert_dev(struct pci_dev *dev)}/* Walk resources on this device, poke them into the tree */-for(i=0;i<DEVICE_COUNT_RESOURCE;i++){+for(i=0;i<=PCI_ROM_RESOURCE;i++){resource_size_tstart=pci_resource_start(dev,i);resource_size_tend=pci_resource_end(dev,i);unsignedlongflags=pci_resource_flags(dev,i);
VFs and their corresponding pci_dn instances are created and released
dynamically as their PF's SRIOV capability is enabled and disabled.
The patch creates and releases EEH devices for VFs when creating and
releasing their pci_dn instances, which means EEH devices and pci_dn
instances have same life cycle. Also, VF's EEH device is identified
by (struct eeh_dev::physfn).
[gwshan: changelog and removed CONFIG_PCI_IOV]
Signed-off-by: Wei Yang <redacted>
Acked-by: Gavin Shan <redacted>
---
arch/powerpc/include/asm/eeh.h | 1 +
arch/powerpc/kernel/pci_dn.c | 12 ++++++++++++
2 files changed, 13 insertions(+)
@@ -180,7 +180,9 @@ static struct pci_dn *add_one_dev_pci_data(struct pci_dn *parent,structpci_dn*add_dev_pci_data(structpci_dev*pdev){#ifdef CONFIG_PCI_IOV+structpci_controller*hose=pci_bus_to_host(pdev->bus);structpci_dn*parent,*pdn;+structeeh_dev*edev;inti;/* Only support IOV for now */
Current EEH recovery code works with the assumption: the PE has primary
bus. Unfortunately, that's not true for VF PEs, which generally contains
one or multiple VFs (for VF group case).
The patch creates PEs for VFs in the weak function
pcibios_bus_add_device(). Those PEs for VFs are identified with newly
introduced flag EEH_PE_VF so that we handle them differently during EEH
recovery.
[gwshan: changelog and code refactoring]
Signed-off-by: Wei Yang <redacted>
Acked-by: Gavin Shan <redacted>
---
arch/powerpc/include/asm/eeh.h | 1 +
arch/powerpc/kernel/eeh_pe.c | 10 ++++++++--
arch/powerpc/platforms/powernv/eeh-powernv.c | 16 ++++++++++++++++
3 files changed, 25 insertions(+), 2 deletions(-)
@@ -299,7 +299,10 @@ static struct eeh_pe *eeh_pe_get_parent(struct eeh_dev *edev)*EEHdevicealreadyhavingassociatedPE,but*thedirectparentEEHdevicedoesn'thaveyet.*/-pdn=pdn?pdn->parent:NULL;+if(edev->physfn)+pdn=pci_get_pdn(edev->physfn);+else+pdn=pdn?pdn->parent:NULL;while(pdn){/* We're poking out of PCI territory */parent=pdn_to_eeh_dev(pdn);
@@ -382,7 +385,10 @@ int eeh_add_to_parent_pe(struct eeh_dev *edev)}/* Create a new EEH PE */-pe=eeh_pe_alloc(edev->phb,EEH_PE_DEVICE);+if(edev->physfn)+pe=eeh_pe_alloc(edev->phb,EEH_PE_VF);+else+pe=eeh_pe_alloc(edev->phb,EEH_PE_DEVICE);if(!pe){pr_err("%s: out of memory!\n",__func__);return-ENOMEM;
PEs for VFs don't have primary bus. So they have to have their own reset
backend, which is used during EEH recovery. The patch implements the reset
backend for VF's PE by issuing FLR or AF FLR to the VFs, which are contained
in the PE.
[gwshan: changelog and code refactoring]
Signed-off-by: Wei Yang <redacted>
Acked-by: Gavin Shan <redacted>
---
arch/powerpc/include/asm/eeh.h | 1 +
arch/powerpc/platforms/powernv/eeh-powernv.c | 134 +++++++++++++++++++++++++-
2 files changed, 134 insertions(+), 1 deletion(-)
@@ -136,6 +136,7 @@ struct eeh_dev {intpcix_cap;/* Saved PCIx capability */intpcie_cap;/* Saved PCIe capability */intaer_cap;/* Saved AER capability */+intaf_cap;/* Saved AF capability */structeeh_pe*pe;/* Associated PE */structlist_headlist;/* Form link list in the PE */structpci_controller*phb;/* Associated PHB */
@@ -893,6 +894,127 @@ static int pnv_eeh_bridge_reset(struct pci_dev *dev, int option)return0;}+staticvoidpnv_eeh_wait_for_pending(structpci_dn*pdn,intpos,+u16mask,boolaf_flr_rst)+{+structeeh_dev*edev=pdn_to_eeh_dev(pdn);+intstatus,i;++/* Wait for Transaction Pending bit to be cleared */+for(i=0;i<4;i++){+eeh_ops->read_config(pdn,pos,2,&status);+if(!(status&mask))+return;++msleep((1<<i)*100);+}++pr_warn("%s: Pending transaction while issuing %s FLR to "+"%04x:%02x:%02x.%01x\n",+__func__,af_flr_rst?"AF":"",+edev->phb->global_number,pdn->busno,+PCI_SLOT(pdn->devfn),PCI_FUNC(pdn->devfn));+}++staticintpnv_eeh_do_flr(structpci_dn*pdn,intoption)+{+structeeh_dev*edev=pdn_to_eeh_dev(pdn);+u32reg;++if(!edev->pcie_cap)+return-ENOTTY;++eeh_ops->read_config(pdn,edev->pcie_cap+PCI_EXP_DEVCAP,4,®);+if(!(reg&PCI_EXP_DEVCAP_FLR))+return-ENOTTY;++switch(option){+caseEEH_RESET_HOT:+caseEEH_RESET_FUNDAMENTAL:+pnv_eeh_wait_for_pending(pdn,edev->pcie_cap+PCI_EXP_DEVSTA,+PCI_EXP_DEVSTA_TRPND,false);+eeh_ops->read_config(pdn,edev->pcie_cap+PCI_EXP_DEVCTL,+4,®);+reg|=PCI_EXP_DEVCTL_BCR_FLR;+eeh_ops->write_config(pdn,edev->pcie_cap+PCI_EXP_DEVCTL,+4,reg);+msleep(EEH_PE_RST_HOLD_TIME);+break;+caseEEH_RESET_DEACTIVATE:+eeh_ops->read_config(pdn,edev->pcie_cap+PCI_EXP_DEVCTL,+4,®);+reg&=~PCI_EXP_DEVCTL_BCR_FLR;+eeh_ops->write_config(pdn,edev->pcie_cap+PCI_EXP_DEVCTL,+4,reg);+msleep(EEH_PE_RST_SETTLE_TIME);+break;+}++return0;+}++staticintpnv_eeh_do_af_flr(structpci_dn*pdn,intoption)+{+structeeh_dev*edev=pdn_to_eeh_dev(pdn);+u32cap;++if(!edev->af_cap)+return-ENOTTY;++eeh_ops->read_config(pdn,edev->af_cap+PCI_AF_CAP,1,&cap);+if(!(cap&PCI_AF_CAP_TP)||!(cap&PCI_AF_CAP_FLR))+return-ENOTTY;++switch(option){+caseEEH_RESET_HOT:+caseEEH_RESET_FUNDAMENTAL:+/*+*WaitforTransactionPendingbittoclear.Aword-aligned+*testisused,soweusetheconroloffsetratherthanstatus+*andshiftthetestbittomatch.+*/+pnv_eeh_wait_for_pending(pdn,edev->af_cap+PCI_AF_CTRL,+PCI_AF_STATUS_TP<<8,true);+eeh_ops->write_config(pdn,edev->af_cap+PCI_AF_CTRL,+1,PCI_AF_CTRL_FLR);+msleep(EEH_PE_RST_HOLD_TIME);+break;+caseEEH_RESET_DEACTIVATE:+eeh_ops->write_config(pdn,edev->af_cap+PCI_AF_CTRL,1,0);+msleep(EEH_PE_RST_SETTLE_TIME);+break;+}++return0;+}++staticintpnv_eeh_reset_vf(structpci_dn*pdn,intoption)+{+intret;++ret=pnv_eeh_do_flr(pdn,option);+if(ret!=-ENOTTY)+returnret;++returnpnv_eeh_do_af_flr(pdn,option);+}++staticintpnv_eeh_vf_pe_reset(structeeh_pe*pe,intoption)+{+structeeh_dev*edev,*tmp;+structpci_dn*pdn;+intret;++eeh_pe_for_each_dev(pe,edev,tmp){+pdn=eeh_dev_to_pdn(edev);+ret=pnv_eeh_reset_vf(pdn,option);+if(ret)+returnret;+}++return0;+}+voidpnv_pci_reset_secondary_bus(structpci_dev*dev){structpci_controller*hose;
@@ -968,7 +1090,9 @@ static int pnv_eeh_reset(struct eeh_pe *pe, int option)}bus=eeh_pe_bus_get(pe);-if(pci_is_root_bus(bus)||+if(pe->type&EEH_PE_VF)+ret=pnv_eeh_vf_pe_reset(pe,option);+elseif(pci_is_root_bus(bus)||pci_is_root_bus(bus->parent))ret=pnv_eeh_root_reset(hose,option);else
After PE reset, OPAL API opal_pci_reinit() is called on all devices
contained in the PE to reinitialize them. However, VFs can't be seen
from skiboot firmware. We have to implement the functions, similar
those in skiboot firmware, to reinitialize VFs after reset on PE
for VFs.
[gwshan: changelog and code refactoring]
Signed-off-by: Wei Yang <redacted>
Acked-by: Gavin Shan <redacted>
---
arch/powerpc/include/asm/pci-bridge.h | 1 +
arch/powerpc/platforms/powernv/eeh-powernv.c | 70 +++++++++++++++++++++++++-
arch/powerpc/platforms/powernv/pci.c | 18 +++++++
3 files changed, 88 insertions(+), 1 deletion(-)
As commit ac205b7bb72f ("PCI: make sriov work with hotplug remove") indicates,
VFs, which might be hooked to same PCI bus as their PF should be removed
before the PF. Otherwise, the PCI hot unplugging on the PCI bus would
cause kernel crash.
The patch applies the above pattern to PowerPC PCI hotplug path.
[gwshan: changelog]
Signed-off-by: Wei Yang <redacted>
Acked-by: Gavin Shan <redacted>
---
arch/powerpc/kernel/pci-hotplug.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
When VF BAR size is larger than 64MB, we group VFs in terms of M64 BAR,
which means those VFs in a group should form a compound PE.
This patch links those VF PEs into compound PE in this case.
[gwshan: code refactoring for a bit]
Signed-off-by: Wei Yang <redacted>
Acked-by: Gavin Shan <redacted>
---
arch/powerpc/platforms/powernv/pci-ioda.c | 46 +++++++++++++++++++++++++----
arch/powerpc/platforms/powernv/pci.c | 17 +++++++++--
2 files changed, 56 insertions(+), 7 deletions(-)
@@ -1456,10 +1467,13 @@ static void pnv_ioda_setup_vf_PE(struct pci_dev *pdev, u16 num_vfs)continue;}-/* Put PE to the list */-mutex_lock(&phb->ioda.pe_list_mutex);-list_add_tail(&pe->list,&phb->ioda.pe_list);-mutex_unlock(&phb->ioda.pe_list_mutex);+/* Put PE to the list, or postpone it for compound PEs */+if((pdn->m64_per_iov!=M64_PER_IOV)||+(num_vfs<=M64_PER_IOV)){+mutex_lock(&phb->ioda.pe_list_mutex);+list_add_tail(&pe->list,&phb->ioda.pe_list);+mutex_unlock(&phb->ioda.pe_list_mutex);+}pnv_pci_ioda2_setup_dma_pe(phb,pe);}
Different from PCI bus dependent PE, PE for VFs doesn't have the
primary bus, on which the PCI hotplug is implemented. The patch
supports error recovery, especially the PCI hotplug for VF's PE.
The hotplug on VF's PE is implemented based on VFs, instead of
PCI bus any more.
[gwshan: changelog and code refactoring]
Signed-off-by: Wei Yang <redacted>
Acked-by: Gavin Shan <redacted>
---
arch/powerpc/include/asm/eeh.h | 1 +
arch/powerpc/kernel/eeh.c | 8 +++
arch/powerpc/kernel/eeh_driver.c | 100 ++++++++++++++++++++++++++++++--------
arch/powerpc/kernel/eeh_pe.c | 3 +-
4 files changed, 90 insertions(+), 22 deletions(-)
@@ -548,6 +590,7 @@ static int eeh_reset_device(struct eeh_pe *pe, struct pci_bus *bus)structpci_bus*frozen_bus=eeh_pe_bus_get(pe);structtimevaltstamp;intcnt,rc,removed=0;+structeeh_dev*edev;/* pcibios will clear the counter; save the value */cnt=pe->freeze_count;
Hi, Michael
Hope you didn't take this yet. We may change this patch a little.
On Fri, Jul 17, 2015 at 02:02:41PM +0800, Wei Yang wrote:
quoted hunk
When VF BAR size is larger than 64MB, we group VFs in terms of M64 BAR,
which means those VFs in a group should form a compound PE.
This patch links those VF PEs into compound PE in this case.
[gwshan: code refactoring for a bit]
Signed-off-by: Wei Yang <redacted>
Acked-by: Gavin Shan <redacted>
---
arch/powerpc/platforms/powernv/pci-ioda.c | 46 +++++++++++++++++++++++++----
arch/powerpc/platforms/powernv/pci.c | 17 +++++++++--
2 files changed, 56 insertions(+), 7 deletions(-)
continue;
}
- /* Put PE to the list */
- mutex_lock(&phb->ioda.pe_list_mutex);
- list_add_tail(&pe->list, &phb->ioda.pe_list);
- mutex_unlock(&phb->ioda.pe_list_mutex);
+ /* Put PE to the list, or postpone it for compound PEs */
+ if ((pdn->m64_per_iov != M64_PER_IOV) ||
+ (num_vfs <= M64_PER_IOV)) {
+ mutex_lock(&phb->ioda.pe_list_mutex);
+ list_add_tail(&pe->list, &phb->ioda.pe_list);
+ mutex_unlock(&phb->ioda.pe_list_mutex);
+ }
pnv_pci_ioda2_setup_dma_pe(phb, pe);
}
On Wed, Jul 29, 2015 at 11:17:18AM +0800, Wei Yang wrote:
Hi, Michael
Hope you didn't take this yet. We may change this patch a little.
[Cc Alexey who might concern the SRIOV status]
Richard, do you have plan to get it upstream? It seems it's hanged
over here for long time.
On Fri, Jul 17, 2015 at 02:02:41PM +0800, Wei Yang wrote:
quoted
When VF BAR size is larger than 64MB, we group VFs in terms of M64 BAR,
which means those VFs in a group should form a compound PE.
This patch links those VF PEs into compound PE in this case.
[gwshan: code refactoring for a bit]
Signed-off-by: Wei Yang <redacted>
Acked-by: Gavin Shan <redacted>
---
arch/powerpc/platforms/powernv/pci-ioda.c | 46 +++++++++++++++++++++++++----
arch/powerpc/platforms/powernv/pci.c | 17 +++++++++--
2 files changed, 56 insertions(+), 7 deletions(-)
continue;
}
- /* Put PE to the list */
- mutex_lock(&phb->ioda.pe_list_mutex);
- list_add_tail(&pe->list, &phb->ioda.pe_list);
- mutex_unlock(&phb->ioda.pe_list_mutex);
+ /* Put PE to the list, or postpone it for compound PEs */
+ if ((pdn->m64_per_iov != M64_PER_IOV) ||
+ (num_vfs <= M64_PER_IOV)) {
+ mutex_lock(&phb->ioda.pe_list_mutex);
+ list_add_tail(&pe->list, &phb->ioda.pe_list);
+ mutex_unlock(&phb->ioda.pe_list_mutex);
+ }
pnv_pci_ioda2_setup_dma_pe(phb, pe);
}
From: Richard Yang <hidden> Date: 2015-09-09 03:36:26
On Wed, Sep 09, 2015 at 12:48:21PM +1000, Gavin Shan wrote:
On Wed, Jul 29, 2015 at 11:17:18AM +0800, Wei Yang wrote:
quoted
Hi, Michael
Hope you didn't take this yet. We may change this patch a little.
[Cc Alexey who might concern the SRIOV status]
Richard, do you have plan to get it upstream? It seems it's hanged
over here for long time.
The VF EEH is hung since we re-designed the SRIOV. After the re-design, we
don't have VF groups.
My plan is to push the VF EEH patch set after the SRIOV Redesign is accepted.
quoted
On Fri, Jul 17, 2015 at 02:02:41PM +0800, Wei Yang wrote:
quoted
When VF BAR size is larger than 64MB, we group VFs in terms of M64 BAR,
which means those VFs in a group should form a compound PE.
This patch links those VF PEs into compound PE in this case.
[gwshan: code refactoring for a bit]
Signed-off-by: Wei Yang <redacted>
Acked-by: Gavin Shan <redacted>
---
arch/powerpc/platforms/powernv/pci-ioda.c | 46 +++++++++++++++++++++++++----
arch/powerpc/platforms/powernv/pci.c | 17 +++++++++--
2 files changed, 56 insertions(+), 7 deletions(-)
continue;
}
- /* Put PE to the list */
- mutex_lock(&phb->ioda.pe_list_mutex);
- list_add_tail(&pe->list, &phb->ioda.pe_list);
- mutex_unlock(&phb->ioda.pe_list_mutex);
+ /* Put PE to the list, or postpone it for compound PEs */
+ if ((pdn->m64_per_iov != M64_PER_IOV) ||
+ (num_vfs <= M64_PER_IOV)) {
+ mutex_lock(&phb->ioda.pe_list_mutex);
+ list_add_tail(&pe->list, &phb->ioda.pe_list);
+ mutex_unlock(&phb->ioda.pe_list_mutex);
+ }
pnv_pci_ioda2_setup_dma_pe(phb, pe);
}
On Wed, Sep 09, 2015 at 11:36:16AM +0800, Richard Yang wrote:
On Wed, Sep 09, 2015 at 12:48:21PM +1000, Gavin Shan wrote:
quoted
On Wed, Jul 29, 2015 at 11:17:18AM +0800, Wei Yang wrote:
quoted
Hi, Michael
Hope you didn't take this yet. We may change this patch a little.
[Cc Alexey who might concern the SRIOV status]
Richard, do you have plan to get it upstream? It seems it's hanged
over here for long time.
The VF EEH is hung since we re-designed the SRIOV. After the re-design, we
don't have VF groups.
How can this SRIOV redesign patchset affect EEH part greatly? The EEH
VF patchset already support VF PE which contains only one VF.
My plan is to push the VF EEH patch set after the SRIOV Redesign is accepted.
That SRIOV redesign patchset missed 4.3 merge window obviously. I think the
code has been reviewed by Alexey and me. If Alexey isn't going to have more
comments about it, you can refresh the series (EEH support for VF) based on
it and send the updated series. I don't think there is any dependencies.
quoted
quoted
On Fri, Jul 17, 2015 at 02:02:41PM +0800, Wei Yang wrote:
quoted
When VF BAR size is larger than 64MB, we group VFs in terms of M64 BAR,
which means those VFs in a group should form a compound PE.
This patch links those VF PEs into compound PE in this case.
[gwshan: code refactoring for a bit]
Signed-off-by: Wei Yang <redacted>
Acked-by: Gavin Shan <redacted>
---
arch/powerpc/platforms/powernv/pci-ioda.c | 46 +++++++++++++++++++++++++----
arch/powerpc/platforms/powernv/pci.c | 17 +++++++++--
2 files changed, 56 insertions(+), 7 deletions(-)
continue;
}
- /* Put PE to the list */
- mutex_lock(&phb->ioda.pe_list_mutex);
- list_add_tail(&pe->list, &phb->ioda.pe_list);
- mutex_unlock(&phb->ioda.pe_list_mutex);
+ /* Put PE to the list, or postpone it for compound PEs */
+ if ((pdn->m64_per_iov != M64_PER_IOV) ||
+ (num_vfs <= M64_PER_IOV)) {
+ mutex_lock(&phb->ioda.pe_list_mutex);
+ list_add_tail(&pe->list, &phb->ioda.pe_list);
+ mutex_unlock(&phb->ioda.pe_list_mutex);
+ }
pnv_pci_ioda2_setup_dma_pe(phb, pe);
}
From: Benjamin Herrenschmidt <hidden> Date: 2015-09-09 05:00:15
On Wed, 2015-09-09 at 11:36 +0800, Richard Yang wrote:
The VF EEH is hung since we re-designed the SRIOV. After the re
-design, we
don't have VF groups.
My plan is to push the VF EEH patch set after the SRIOV Redesign is
accepted.
What do you mean taht we don't have VF groups ?
If we don't have IOMMU groups per VF that means we can't assign them to
KVM partitions -> they are completely useless.
Ben.
On Wed, Sep 09, 2015 at 12:48:21PM +1000, Gavin Shan wrote:
quoted
On Wed, Jul 29, 2015 at 11:17:18AM +0800, Wei Yang wrote:
quoted
Hi, Michael
Hope you didn't take this yet. We may change this patch a little.
[Cc Alexey who might concern the SRIOV status]
Richard, do you have plan to get it upstream? It seems it's hanged
over here for long time.
The VF EEH is hung since we re-designed the SRIOV. After the re-design, we
don't have VF groups.
My plan is to push the VF EEH patch set after the SRIOV Redesign is accepted.
Can you please rebase on v4.2 (or v4.2 + sriov rework) and repost VF EEH
patchset just to me? Or share the tree somewhere where I can pull it from?
Thanks.
As for now, I cannot tell what difference your SRIOV patchset actually makes.
--
Alexey
From: Richard Yang <hidden> Date: 2015-09-09 05:53:37
On Wed, Sep 09, 2015 at 02:59:11PM +1000, Benjamin Herrenschmidt wrote:
On Wed, 2015-09-09 at 11:36 +0800, Richard Yang wrote:
quoted
The VF EEH is hung since we re-designed the SRIOV. After the re
-design, we
don't have VF groups.
My plan is to push the VF EEH patch set after the SRIOV Redesign is
accepted.
What do you mean taht we don't have VF groups ?
Before we redesign the SRIOV, several VFs may share one M64 segment. This
introduced the compound PE for VFs. The VF group in previous mail means the
compound PE composed of a master VF PE will have several slave VF PEs.
If we don't have IOMMU groups per VF that means we can't assign them to
KVM partitions -> they are completely useless.
From: Richard Yang <hidden> Date: 2015-09-09 06:00:55
On Wed, Sep 09, 2015 at 01:52:32PM +1000, Gavin Shan wrote:
tatus: O
Content-Length: 6303
Lines: 176
On Wed, Sep 09, 2015 at 11:36:16AM +0800, Richard Yang wrote:
quoted
On Wed, Sep 09, 2015 at 12:48:21PM +1000, Gavin Shan wrote:
quoted
On Wed, Jul 29, 2015 at 11:17:18AM +0800, Wei Yang wrote:
quoted
Hi, Michael
Hope you didn't take this yet. We may change this patch a little.
[Cc Alexey who might concern the SRIOV status]
Richard, do you have plan to get it upstream? It seems it's hanged
over here for long time.
The VF EEH is hung since we re-designed the SRIOV. After the re-design, we
don't have VF groups.
How can this SRIOV redesign patchset affect EEH part greatly? The EEH
VF patchset already support VF PE which contains only one VF.
Yes, that's not greatly. Mostly the difference after SRIOV redesign is the
last patch "powerpc/powernv: compound PE for VFs" will be removed.
quoted
My plan is to push the VF EEH patch set after the SRIOV Redesign is accepted.
That SRIOV redesign patchset missed 4.3 merge window obviously. I think the
code has been reviewed by Alexey and me. If Alexey isn't going to have more
comments about it, you can refresh the series (EEH support for VF) based on
it and send the updated series. I don't think there is any dependencies.
The difference is simple, while we can't apply a patch series without the last
patch in this thread to the upstream. The upstream version will have the
compound VF PE, while after SRIOV Redesign, we don't.
quoted
quoted
quoted
On Fri, Jul 17, 2015 at 02:02:41PM +0800, Wei Yang wrote:
quoted
When VF BAR size is larger than 64MB, we group VFs in terms of M64 BAR,
which means those VFs in a group should form a compound PE.
This patch links those VF PEs into compound PE in this case.
[gwshan: code refactoring for a bit]
Signed-off-by: Wei Yang <redacted>
Acked-by: Gavin Shan <redacted>
---
arch/powerpc/platforms/powernv/pci-ioda.c | 46 +++++++++++++++++++++++++----
arch/powerpc/platforms/powernv/pci.c | 17 +++++++++--
2 files changed, 56 insertions(+), 7 deletions(-)
continue;
}
- /* Put PE to the list */
- mutex_lock(&phb->ioda.pe_list_mutex);
- list_add_tail(&pe->list, &phb->ioda.pe_list);
- mutex_unlock(&phb->ioda.pe_list_mutex);
+ /* Put PE to the list, or postpone it for compound PEs */
+ if ((pdn->m64_per_iov != M64_PER_IOV) ||
+ (num_vfs <= M64_PER_IOV)) {
+ mutex_lock(&phb->ioda.pe_list_mutex);
+ list_add_tail(&pe->list, &phb->ioda.pe_list);
+ mutex_unlock(&phb->ioda.pe_list_mutex);
+ }
pnv_pci_ioda2_setup_dma_pe(phb, pe);
}
From: Richard Yang <hidden> Date: 2015-09-09 06:01:56
On Wed, Sep 09, 2015 at 03:22:08PM +1000, Alexey Kardashevskiy wrote:
On 09/09/2015 01:36 PM, Richard Yang wrote:
quoted
On Wed, Sep 09, 2015 at 12:48:21PM +1000, Gavin Shan wrote:
quoted
On Wed, Jul 29, 2015 at 11:17:18AM +0800, Wei Yang wrote:
quoted
Hi, Michael
Hope you didn't take this yet. We may change this patch a little.
[Cc Alexey who might concern the SRIOV status]
Richard, do you have plan to get it upstream? It seems it's hanged
over here for long time.
The VF EEH is hung since we re-designed the SRIOV. After the re-design, we
don't have VF groups.
My plan is to push the VF EEH patch set after the SRIOV Redesign is accepted.
Can you please rebase on v4.2 (or v4.2 + sriov rework) and repost VF EEH
patchset just to me? Or share the tree somewhere where I can pull it from?
Thanks.
Yep, this is what I am planning to do.
As for now, I cannot tell what difference your SRIOV patchset actually makes.
--
Alexey
On Wed, Sep 09, 2015 at 02:01:29PM +0800, Richard Yang wrote:
On Wed, Sep 09, 2015 at 03:22:08PM +1000, Alexey Kardashevskiy wrote:
quoted
On 09/09/2015 01:36 PM, Richard Yang wrote:
quoted
On Wed, Sep 09, 2015 at 12:48:21PM +1000, Gavin Shan wrote:
quoted
On Wed, Jul 29, 2015 at 11:17:18AM +0800, Wei Yang wrote:
quoted
Hi, Michael
Hope you didn't take this yet. We may change this patch a little.
[Cc Alexey who might concern the SRIOV status]
Richard, do you have plan to get it upstream? It seems it's hanged
over here for long time.
The VF EEH is hung since we re-designed the SRIOV. After the re-design, we
don't have VF groups.
My plan is to push the VF EEH patch set after the SRIOV Redesign is accepted.
Can you please rebase on v4.2 (or v4.2 + sriov rework) and repost VF EEH
patchset just to me? Or share the tree somewhere where I can pull it from?
Thanks.
Yep, this is what I am planning to do.
Can you rebase your patchset on v4.3.rc1+sriov rework and then repost to
linux-ppc-dev maillist?
quoted
As for now, I cannot tell what difference your SRIOV patchset actually makes.
--
Alexey