#
65fd766b |
| 24-Apr-2014 |
Gavin Shan <gwshan@linux.vnet.ibm.com> |
powerpc/powernv: Missed IOMMU table type
In function pnv_pci_ioda2_setup_dma_pe(), the IOMMU table type is set to (TCE_PCI_SWINV_CREATE | TCE_PCI_SWINV_FREE) unconditionally. It was just set to TCE_
powerpc/powernv: Missed IOMMU table type
In function pnv_pci_ioda2_setup_dma_pe(), the IOMMU table type is set to (TCE_PCI_SWINV_CREATE | TCE_PCI_SWINV_FREE) unconditionally. It was just set to TCE_PCI by pnv_pci_setup_iommu_table(). So the primary IOMMU table type (TCE_PCI) is lost. The patch fixes it.
Also, pnv_pci_setup_iommu_table() already set "tbl->it_busno" to zero and we needn't do it again. The patch removes the redundant assignment.
The patch also fixes similar issues in pnv_pci_ioda_setup_dma_pe().
Signed-off-by: Gavin Shan <gwshan@linux.vnet.ibm.com> Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
show more ...
|
#
361f2a2a |
| 24-Apr-2014 |
Gavin Shan <gwshan@linux.vnet.ibm.com> |
powrpc/powernv: Reset PHB in kdump kernel
In the kdump scenario, the first kerenl doesn't shutdown PCI devices and the kdump kerenl clean PHB IODA table at the early probe time. That means the kdump
powrpc/powernv: Reset PHB in kdump kernel
In the kdump scenario, the first kerenl doesn't shutdown PCI devices and the kdump kerenl clean PHB IODA table at the early probe time. That means the kdump kerenl can't support PCI transactions piled by the first kerenl. Otherwise, lots of EEH errors and frozen PEs will be detected.
In order to avoid the EEH errors, the PHB is resetted to drop all PCI transaction from the first kerenl.
Signed-off-by: Gavin Shan <gwshan@linux.vnet.ibm.com> Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
show more ...
|
#
d92a208d |
| 24-Apr-2014 |
Gavin Shan <gwshan@linux.vnet.ibm.com> |
powerpc/pci: Mask linkDown on resetting PCI bus
The problem was initially reported by Wendy who tried pass through IPR adapter, which was connected to PHB root port directly, to KVM based guest. Whe
powerpc/pci: Mask linkDown on resetting PCI bus
The problem was initially reported by Wendy who tried pass through IPR adapter, which was connected to PHB root port directly, to KVM based guest. When doing that, pci_reset_bridge_secondary_bus() was called by VFIO driver and linkDown was detected by the root port. That caused all PEs to be frozen.
The patch fixes the issue by routing the reset for the secondary bus of root port to underly firmware. For that, one more weak function pci_reset_secondary_bus() is introduced so that the individual platforms can override that and do specific reset for bridge's secondary bus.
Reported-by: Wendy Xiong <wenxiong@linux.vnet.ibm.com> Signed-off-by: Gavin Shan <gwshan@linux.vnet.ibm.com> Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
show more ...
|
#
4966bfa1 |
| 22-Apr-2014 |
Wei Yang <weiyang@linux.vnet.ibm.com> |
powerpc/powernv: Release the refcount for pci_dev
On PowerNV platform, we are holding an unnecessary refcount on a pci_dev, which leads to the pci_dev is not destroyed when hotplugging a pci device.
powerpc/powernv: Release the refcount for pci_dev
On PowerNV platform, we are holding an unnecessary refcount on a pci_dev, which leads to the pci_dev is not destroyed when hotplugging a pci device.
This patch release the unnecessary refcount.
Signed-off-by: Wei Yang <weiyang@linux.vnet.ibm.com> Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
show more ...
|
#
3f28c5af |
| 22-Apr-2014 |
Wei Yang <weiyang@linux.vnet.ibm.com> |
powerpc/powernv: Reduce multi-hit of iommu_add_device()
During the EEH hotplug event, iommu_add_device() will be invoked three times and two of them will trigger warning or error.
The three times t
powerpc/powernv: Reduce multi-hit of iommu_add_device()
During the EEH hotplug event, iommu_add_device() will be invoked three times and two of them will trigger warning or error.
The three times to invoke the iommu_add_device() are:
pci_device_add ... set_iommu_table_base_and_group <- 1st time, fail device_add ... tce_iommu_bus_notifier <- 2nd time, succees pcibios_add_pci_devices ... pcibios_setup_bus_devices <- 3rd time, re-attach
The first time fails, since the dev->kobj->sd is not initialized. The dev->kobj->sd is initialized in device_add(). The third time's warning is triggered by the re-attach of the iommu_group.
After applying this patch, the error
iommu_tce: 0003:05:00.0 has not been added, ret=-14
and the warning
[ 204.123609] ------------[ cut here ]------------ [ 204.123645] WARNING: at arch/powerpc/kernel/iommu.c:1125 [ 204.123680] Modules linked in: xt_CHECKSUM nf_conntrack_netbios_ns nf_conntrack_broadcast ipt_MASQUERADE ip6t_REJECT bnep bluetooth 6lowpan_iphc rfkill xt_conntrack ebtable_nat ebtable_broute bridge stp llc mlx4_ib ib_sa ib_mad ib_core ib_addr ebtable_filter ebtables ip6table_nat nf_conntrack_ipv6 nf_defrag_ipv6 nf_nat_ipv6 ip6table_mangle ip6table_security ip6table_raw ip6table_filter ip6_tables iptable_nat nf_conntrack_ipv4 nf_defrag_ipv4 nf_nat_ipv4 nf_nat nf_conntrack iptable_mangle iptable_security iptable_raw bnx2x tg3 mlx4_core nfsd ptp mdio ses libcrc32c nfs_acl enclosure be2net pps_core shpchp lockd kvm uinput sunrpc binfmt_misc lpfc scsi_transport_fc ipr scsi_tgt [ 204.124356] CPU: 18 PID: 650 Comm: eehd Not tainted 3.14.0-rc5yw+ #102 [ 204.124400] task: c0000027ed485670 ti: c0000027ed50c000 task.ti: c0000027ed50c000 [ 204.124453] NIP: c00000000003cf80 LR: c00000000006c648 CTR: c00000000006c5c0 [ 204.124506] REGS: c0000027ed50f440 TRAP: 0700 Not tainted (3.14.0-rc5yw+) [ 204.124558] MSR: 9000000000029032 <SF,HV,EE,ME,IR,DR,RI> CR: 88008084 XER: 20000000 [ 204.124682] CFAR: c00000000006c644 SOFTE: 1 GPR00: c00000000006c648 c0000027ed50f6c0 c000000001398380 c0000027ec260300 GPR04: c0000027ea92c000 c00000000006ad00 c0000000016e41b0 0000000000000110 GPR08: c0000000012cd4c0 0000000000000001 c0000027ec2602ff 0000000000000062 GPR12: 0000000028008084 c00000000fdca200 c0000000000d1d90 c0000027ec281a80 GPR16: 0000000000000000 0000000000000000 0000000000000000 0000000000000000 GPR20: 0000000000000000 0000000000000000 0000000000000000 0000000000000001 GPR24: 000000005342697b 0000000000002906 c000001fe6ac9800 c000001fe6ac9800 GPR28: 0000000000000000 c0000000016e3a80 c0000027ea92c090 c0000027ea92c000 [ 204.125353] NIP [c00000000003cf80] .iommu_add_device+0x30/0x1f0 [ 204.125399] LR [c00000000006c648] .pnv_pci_ioda_dma_dev_setup+0x88/0xb0 [ 204.125443] Call Trace: [ 204.125464] [c0000027ed50f6c0] [c0000027ed50f750] 0xc0000027ed50f750 (unreliable) [ 204.125526] [c0000027ed50f750] [c00000000006c648] .pnv_pci_ioda_dma_dev_setup+0x88/0xb0 [ 204.125588] [c0000027ed50f7d0] [c000000000069cc8] .pnv_pci_dma_dev_setup+0x78/0x340 [ 204.125650] [c0000027ed50f870] [c000000000044408] .pcibios_setup_device+0x88/0x2f0 [ 204.125712] [c0000027ed50f940] [c000000000046040] .pcibios_setup_bus_devices+0x60/0xd0 [ 204.125774] [c0000027ed50f9c0] [c000000000043acc] .pcibios_add_pci_devices+0xdc/0x1c0 [ 204.125837] [c0000027ed50fa50] [c00000000086f970] .eeh_reset_device+0x36c/0x4f0 [ 204.125939] [c0000027ed50fb20] [c00000000003a2d8] .eeh_handle_normal_event+0x448/0x480 [ 204.126068] [c0000027ed50fbc0] [c00000000003a35c] .eeh_handle_event+0x4c/0x340 [ 204.126192] [c0000027ed50fc80] [c00000000003a74c] .eeh_event_handler+0xfc/0x1b0 [ 204.126319] [c0000027ed50fd30] [c0000000000d1ea0] .kthread+0x110/0x130 [ 204.126430] [c0000027ed50fe30] [c00000000000a460] .ret_from_kernel_thread+0x5c/0x7c [ 204.126556] Instruction dump: [ 204.126610] 7c0802a6 fba1ffe8 fbc1fff0 fbe1fff8 f8010010 f821ff71 7c7e1b78 60000000 [ 204.126787] 60000000 e87e0298 3143ffff 7d2a1910 <0b090000> 2fa90000 40de00c8 ebfe0218 [ 204.126966] ---[ end trace 6e7aefd80add2973 ]---
are cleared.
This patch removes iommu_add_device() in pnv_pci_ioda_dma_dev_setup(), which revert part of the change in commit d905c5df(PPC: POWERNV: move iommu_add_device earlier).
Signed-off-by: Wei Yang <weiyang@linux.vnet.ibm.com> Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
show more ...
|
Revision tags: v3.15-rc2, v3.15-rc1, v3.14, v3.14-rc8, v3.14-rc7, v3.14-rc6, v3.14-rc5, v3.14-rc4, v3.14-rc3 |
|
#
cd15b048 |
| 10-Feb-2014 |
Benjamin Herrenschmidt <benh@kernel.crashing.org> |
powerpc/powernv: Add iommu DMA bypass support for IODA2
This patch adds the support for to create a direct iommu "bypass" window on IODA2 bridges (such as Power8) allowing to bypass iommu page trans
powerpc/powernv: Add iommu DMA bypass support for IODA2
This patch adds the support for to create a direct iommu "bypass" window on IODA2 bridges (such as Power8) allowing to bypass iommu page translation completely for 64-bit DMA capable devices, thus significantly improving DMA performances.
Additionally, this adds a hook to the struct iommu_table so that the IOMMU API / VFIO can disable the bypass when external ownership is requested, since in that case, the device will be used by an environment such as userspace or a KVM guest which must not be allowed to bypass translations.
Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
show more ...
|
Revision tags: v3.14-rc2, v3.14-rc1, v3.13, v3.13-rc8, v3.13-rc7, v3.13-rc6 |
|
#
8184616f |
| 25-Dec-2013 |
Gavin Shan <shangw@linux.vnet.ibm.com> |
powerpc/powernv: Remove unnecessary assignment
We don't have IO ports on PHB3 and the assignment of variable "iomap_off" on PHB3 is meaningless. The patch just removes the unnecessary assignment to
powerpc/powernv: Remove unnecessary assignment
We don't have IO ports on PHB3 and the assignment of variable "iomap_off" on PHB3 is meaningless. The patch just removes the unnecessary assignment to the variable. The code change should have been part of commit c35d2a8c ("powerpc/powernv: Needn't IO segment map for PHB3").
Signed-off-by: Gavin Shan <shangw@linux.vnet.ibm.com> Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
show more ...
|
Revision tags: v3.13-rc5, v3.13-rc4 |
|
#
08607afb |
| 09-Dec-2013 |
Thadeu Lima de Souza Cascardo <cascardo@linux.vnet.ibm.com> |
powernv: Fix VFIO support with PHB3
I have recently found out that no iommu_groups could be found under /sys/ on a P8. That prevents PCI passthrough from working.
During my investigation, I found o
powernv: Fix VFIO support with PHB3
I have recently found out that no iommu_groups could be found under /sys/ on a P8. That prevents PCI passthrough from working.
During my investigation, I found out there seems to be a missing iommu_register_group for PHB3. The following patch seems to fix the problem. After applying it, I see iommu_groups under /sys/kernel/iommu_groups/, and can also bind vfio-pci to an adapter, which gives me a device at /dev/vfio/.
Signed-off-by: Thadeu Lima de Souza Cascardo <cascardo@linux.vnet.ibm.com> Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
show more ...
|
Revision tags: v3.13-rc3, v3.13-rc2, v3.13-rc1 |
|
#
d905c5df |
| 21-Nov-2013 |
Alexey Kardashevskiy <aik@ozlabs.ru> |
PPC: POWERNV: move iommu_add_device earlier
The current implementation of IOMMU on sPAPR does not use iommu_ops and therefore does not call IOMMU API's bus_set_iommu() which 1) sets iommu_ops for a
PPC: POWERNV: move iommu_add_device earlier
The current implementation of IOMMU on sPAPR does not use iommu_ops and therefore does not call IOMMU API's bus_set_iommu() which 1) sets iommu_ops for a bus 2) registers a bus notifier Instead, PCI devices are added to IOMMU groups from subsys_initcall_sync(tce_iommu_init) which does basically the same thing without using iommu_ops callbacks.
However Freescale PAMU driver (https://lkml.org/lkml/2013/7/1/158) implements iommu_ops and when tce_iommu_init is called, every PCI device is already added to some group so there is a conflict.
This patch does 2 things: 1. removes the loop in which PCI devices were added to groups and adds explicit iommu_add_device() calls to add devices as soon as they get the iommu_table pointer assigned to them. 2. moves a bus notifier to powernv code in order to avoid conflict with the notifier from Freescale driver.
iommu_add_device() and iommu_del_device() are public now.
Signed-off-by: Alexey Kardashevskiy <aik@ozlabs.ru> Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
show more ...
|
#
36954dc7 |
| 04-Nov-2013 |
Gavin Shan <shangw@linux.vnet.ibm.com> |
powerpc/powernv: Reserve the correct PE number
We're assigning PE numbers after the completion of PCI probe. During the PCI probe, we had PE#0 as the super container to encompass all PCI devices. Ho
powerpc/powernv: Reserve the correct PE number
We're assigning PE numbers after the completion of PCI probe. During the PCI probe, we had PE#0 as the super container to encompass all PCI devices. However, that's inappropriate since PELTM has ascending order of priority on search on P7IOC. So we need PE#127 takes the role that PE#0 has previously. For PHB3, we still have PE#0 as the reserved PE.
The patch supposes that the underly firmware has built the RID to PE# mapping after resetting IODA tables: all PELTM entries except last one has invalid mapping on P7IOC, but all RTEs have binding to PE#0. The reserved PE# is being exported by firmware by device tree.
Signed-off-by: Gavin Shan <shangw@linux.vnet.ibm.com> Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
show more ...
|
#
631ad691 |
| 04-Nov-2013 |
Gavin Shan <shangw@linux.vnet.ibm.com> |
powerpc/powernv: Add PE to its own PELTV
We need add PE to its own PELTV. Otherwise, the errors originated from the PE might contribute to other PEs. In the result, we can't clear up the error succe
powerpc/powernv: Add PE to its own PELTV
We need add PE to its own PELTV. Otherwise, the errors originated from the PE might contribute to other PEs. In the result, we can't clear up the error successfully even we're checking and clearing errors during access to PCI config space.
Cc: stable@vger.kernel.org Reported-by: kalshett@in.ibm.com Signed-off-by: Gavin Shan <shangw@linux.vnet.ibm.com> Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
show more ...
|
Revision tags: v3.12, v3.12-rc7, v3.12-rc6, v3.12-rc5, v3.12-rc4, v3.12-rc3, v3.12-rc2, v3.12-rc1, v3.11 |
|
#
8e0a1611 |
| 28-Aug-2013 |
Alexey Kardashevskiy <aik@ozlabs.ru> |
powerpc: add real mode support for dma operations on powernv
The existing TCE machine calls (tce_build and tce_free) only support virtual mode as they call __raw_writeq for TCE invalidation what fai
powerpc: add real mode support for dma operations on powernv
The existing TCE machine calls (tce_build and tce_free) only support virtual mode as they call __raw_writeq for TCE invalidation what fails in real mode.
This introduces tce_build_rm and tce_free_rm real mode versions which do mostly the same but use "Store Doubleword Caching Inhibited Indexed" instruction for TCE invalidation.
This new feature is going to be utilized by real mode support of VFIO.
Signed-off-by: Alexey Kardashevskiy <aik@ozlabs.ru> Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
show more ...
|
#
5e4da530 |
| 22-Sep-2013 |
Anton Blanchard <anton@samba.org> |
powerpc/powernv: Fix some PCI sparse errors and one LE bug
pnv_pci_setup_bml_iommu was missing a byteswap of a device tree property.
Signed-off-by: Anton Blanchard <anton@samba.org> Signed-off-by:
powerpc/powernv: Fix some PCI sparse errors and one LE bug
pnv_pci_setup_bml_iommu was missing a byteswap of a device tree property.
Signed-off-by: Anton Blanchard <anton@samba.org> Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
show more ...
|
#
3a1a4661 |
| 22-Sep-2013 |
Benjamin Herrenschmidt <benh@kernel.crashing.org> |
powerpc/powernv: Fix endian issues in powernv PCI code
Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
|
#
c681b93c |
| 22-Sep-2013 |
Alistair Popple <alistair@popple.id.au> |
powerpc: Little endian sparse clean up for arch/powerpc/platforms/powernv/pci-ioda.c
Signed-off-by: Alistair Popple <alistair@popple.id.au> Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashin
powerpc: Little endian sparse clean up for arch/powerpc/platforms/powernv/pci-ioda.c
Signed-off-by: Alistair Popple <alistair@popple.id.au> Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
show more ...
|
Revision tags: v3.11-rc7, v3.11-rc6, v3.11-rc5, v3.11-rc4 |
|
#
c35d2a8c |
| 31-Jul-2013 |
Gavin Shan <shangw@linux.vnet.ibm.com> |
powerpc/powernv: Needn't IO segment map for PHB3
PHB3 doesn't support IO ports and we needn't IO segment map for that.
Signed-off-by: Gavin Shan <shangw@linux.vnet.ibm.com> Signed-off-by: Benjamin
powerpc/powernv: Needn't IO segment map for PHB3
PHB3 doesn't support IO ports and we needn't IO segment map for that.
Signed-off-by: Gavin Shan <shangw@linux.vnet.ibm.com> Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
show more ...
|
#
2f1ec02e |
| 31-Jul-2013 |
Gavin Shan <shangw@linux.vnet.ibm.com> |
powerpc/powernv: Check primary PHB through ID
The index of one specific PCI controller (struct pci_controller:: global_number) can tell that it's primary one or not. So we needn't additional variabl
powerpc/powernv: Check primary PHB through ID
The index of one specific PCI controller (struct pci_controller:: global_number) can tell that it's primary one or not. So we needn't additional variable for that and just remove it.
Signed-off-by: Gavin Shan <shangw@linux.vnet.ibm.com> Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
show more ...
|
#
f1b7cc3e |
| 31-Jul-2013 |
Gavin Shan <shangw@linux.vnet.ibm.com> |
powerpc/powernv: Fetch PHB bus range from dev-tree
The patch enables fetching bus range from device-tree for the specific PHB. If we can't get that from device-tree, the default range [0 255] will b
powerpc/powernv: Fetch PHB bus range from dev-tree
The patch enables fetching bus range from device-tree for the specific PHB. If we can't get that from device-tree, the default range [0 255] will be used.
Signed-off-by: Gavin Shan <shangw@linux.vnet.ibm.com> Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
show more ...
|
#
58d714ec |
| 31-Jul-2013 |
Gavin Shan <shangw@linux.vnet.ibm.com> |
powerpc/powernv: Free PHB instance upon error
We don't free PHB instance (struct pnv_phb) on error to creating the associated PCI controler (struct pci_controller). The patch fixes that. Also, the o
powerpc/powernv: Free PHB instance upon error
We don't free PHB instance (struct pnv_phb) on error to creating the associated PCI controler (struct pci_controller). The patch fixes that. Also, the output messages have been cleaned for a bit so that they looks unified for IODA_1/2 cases.
Signed-off-by: Gavin Shan <shangw@linux.vnet.ibm.com> Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
show more ...
|
Revision tags: v3.11-rc3, v3.11-rc2, v3.11-rc1 |
|
#
67975005 |
| 02-Jul-2013 |
Bjorn Helgaas <bhelgaas@google.com> |
powerpc/powernv: Mark pnv_pci_init_ioda2_phb() as __init
Mark pnv_pci_init_ioda2_phb() as __init. It is called only from an init function (pnv_pci_init()), and it calls an init function (pnv_pci_in
powerpc/powernv: Mark pnv_pci_init_ioda2_phb() as __init
Mark pnv_pci_init_ioda2_phb() as __init. It is called only from an init function (pnv_pci_init()), and it calls an init function (pnv_pci_init_ioda_phb()):
pnv_pci_init # init pnv_pci_init_ioda2_phb # non-init pnv_pci_init_ioda_phb # init
This should fix a section mismatch warning.
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com> Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
show more ...
|
#
74251fe2 |
| 01-Jul-2013 |
Benjamin Herrenschmidt <benh@kernel.crashing.org> |
powerpc/powernv: Fix iommu initialization again
So because those things always end up in trainwrecks... In 7846de406 we moved back the iommu initialization earlier, essentially undoing 37f02195b whi
powerpc/powernv: Fix iommu initialization again
So because those things always end up in trainwrecks... In 7846de406 we moved back the iommu initialization earlier, essentially undoing 37f02195b which was causing us endless trouble... except that in the meantime we had merged 959c9bdd58 (to workaround the original breakage) which is now ... broken :-)
This fixes it by doing a partial revert of the latter (we keep the ppc_md. path which will be needed in the hotplug case, which happens also during some EEH error recovery situations).
Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org> CC: <stable@vger.kernel.org> [v3.10]
show more ...
|
Revision tags: v3.10 |
|
#
88b6d14b |
| 27-Jun-2013 |
Gavin Shan <shangw@linux.vnet.ibm.com> |
powerpc/eeh: Fix address catch for PowerNV
On the PowerNV platform, the EEH address cache isn't built correctly because we skipped the EEH devices without binding PE. The patch fixes that.
Signed-o
powerpc/eeh: Fix address catch for PowerNV
On the PowerNV platform, the EEH address cache isn't built correctly because we skipped the EEH devices without binding PE. The patch fixes that.
Signed-off-by: Gavin Shan <shangw@linux.vnet.ibm.com> Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
show more ...
|
Revision tags: v3.10-rc7 |
|
#
37c367f2 |
| 20-Jun-2013 |
Gavin Shan <shangw@linux.vnet.ibm.com> |
powerpc/powernv: Debugfs directory for PHB
The patch creates one debugfs directory ("powerpc/PCIxxxx") for each PHB so that we can hook EEH error injection debugfs entry there in proceeding patch.
powerpc/powernv: Debugfs directory for PHB
The patch creates one debugfs directory ("powerpc/PCIxxxx") for each PHB so that we can hook EEH error injection debugfs entry there in proceeding patch.
Signed-off-by: Gavin Shan <shangw@linux.vnet.ibm.com> Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
show more ...
|
#
e9cc17d4 |
| 20-Jun-2013 |
Gavin Shan <shangw@linux.vnet.ibm.com> |
powerpc/eeh: Initialization for PowerNV
The patch initializes EEH for PowerNV platform. Because the OPAL APIs requires HUB ID, we need trace that through struct pnv_phb.
Signed-off-by: Gavin Shan <
powerpc/eeh: Initialization for PowerNV
The patch initializes EEH for PowerNV platform. Because the OPAL APIs requires HUB ID, we need trace that through struct pnv_phb.
Signed-off-by: Gavin Shan <shangw@linux.vnet.ibm.com> Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
show more ...
|
Revision tags: v3.10-rc6, v3.10-rc5, v3.10-rc4, v3.10-rc3 |
|
#
4e13c1ac |
| 20-May-2013 |
Alexey Kardashevskiy <aik@ozlabs.ru> |
powerpc/vfio: Enable on PowerNV platform
This initializes IOMMU groups based on the IOMMU configuration discovered during the PCI scan on POWERNV (POWER non virtualized) platform. The IOMMU groups
powerpc/vfio: Enable on PowerNV platform
This initializes IOMMU groups based on the IOMMU configuration discovered during the PCI scan on POWERNV (POWER non virtualized) platform. The IOMMU groups are to be used later by the VFIO driver, which is used for PCI pass through.
It also implements an API for mapping/unmapping pages for guest PCI drivers and providing DMA window properties. This API is going to be used later by QEMU-VFIO to handle h_put_tce hypercalls from the KVM guest.
The iommu_put_tce_user_mode() does only a single page mapping as an API for adding many mappings at once is going to be added later.
Although this driver has been tested only on the POWERNV platform, it should work on any platform which supports TCE tables. As h_put_tce hypercall is received by the host kernel and processed by the QEMU (what involves calling the host kernel again), performance is not the best - circa 220MB/s on 10Gb ethernet network.
To enable VFIO on POWER, enable SPAPR_TCE_IOMMU config option and configure VFIO as required.
Cc: David Gibson <david@gibson.dropbear.id.au> Signed-off-by: Alexey Kardashevskiy <aik@ozlabs.ru> Signed-off-by: Paul Mackerras <paulus@samba.org> Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
show more ...
|