From: David Gibson <david@gibson.dropbear.id.au>
To: Alexey Kardashevskiy <aik@ozlabs.ru>
Cc: linuxppc-dev@lists.ozlabs.org,
Alex Williamson <alex.williamson@redhat.com>,
Alistair Popple <alistair@popple.id.au>,
Benjamin Herrenschmidt <benh@kernel.crashing.org>,
Daniel Axtens <dja@axtens.net>,
Gavin Shan <gwshan@linux.vnet.ibm.com>,
Russell Currey <ruscur@russell.cc>
Subject: Re: [PATCH kernel v3 9/9] powerpc/powernv/npu: Enable NVLink pass through
Date: Fri, 15 Apr 2016 14:40:20 +1000 [thread overview]
Message-ID: <20160415044020.GK18218@voom.redhat.com> (raw)
In-Reply-To: <1460450270-42354-10-git-send-email-aik@ozlabs.ru>
[-- Attachment #1: Type: text/plain, Size: 6142 bytes --]
On Tue, Apr 12, 2016 at 06:37:50PM +1000, Alexey Kardashevskiy wrote:
> IBM POWER8 NVlink systems come with Tesla K40-ish GPUs each of which
> also has a couple of fast speed links (NVLink). The interface to links
> is exposed as an emulated PCI bridge which is included into the same
> IOMMU group as the corresponding GPU.
>
> In the kernel, NPUs get a separate PHB of the PNV_PHB_NPU type and a PE.
>
> In order to make these links work when GPU is passed to the guest,
> these bridges need to be passed as well; otherwise performance will
> degrade.
>
> This implements and exports API to manage NPU state in regard to VFIO;
> it replicates iommu_table_group_ops.
>
> This defines a new pnv_pci_ioda2_npu_ops which is assigned to
> the IODA2 bridge if there are NPUs for a GPU on the bridge.
> The new callbacks call the default IODA2 callbacks plus new NPU API.
> This adds a gpe_table_group_to_npe() helper to find NPU PE for the IODA2
> table_group, it is not expected to fail as the helper is only called
> from the pnv_pci_ioda2_npu_ops.
>
> This adds a pnv_pci_npu_setup_iommu() helper which adds NPUs to
> the GPU group if any found. The helper uses helpers to look for
> the "ibm,gpu" property in the device tree which is a phandle of
> the corresponding GPU.
>
> This adds an additional loop over PEs in pnv_ioda_setup_dma() as the main
> loop skips NPU PEs as they do not have 32bit DMA segments.
>
> Signed-off-by: Alexey Kardashevskiy <aik@ozlabs.ru>
> ---
> Changes:
> v3:
> * moved NPU-to-GPU IOMMU grouping later after all PHBs are discovered
> * removed hack to make iommu_add_device() work, iommu_group_add_device()
> is used instead
> * cleanup in gpe_table_group_to_npe_cb()
>
> v2:
> * reimplemented to support NPU + GPU in the same group
> * merged "powerpc/powernv/npu: Add NPU devices to IOMMU group" and
> "powerpc/powernv/npu: Enable passing through via VFIO" into this patch
> ---
> arch/powerpc/platforms/powernv/npu-dma.c | 126 ++++++++++++++++++++++++++++++
> arch/powerpc/platforms/powernv/pci-ioda.c | 105 +++++++++++++++++++++++++
> arch/powerpc/platforms/powernv/pci.h | 6 ++
> 3 files changed, 237 insertions(+)
>
> diff --git a/arch/powerpc/platforms/powernv/npu-dma.c b/arch/powerpc/platforms/powernv/npu-dma.c
> index 8e70221..7cb9f6a 100644
> --- a/arch/powerpc/platforms/powernv/npu-dma.c
> +++ b/arch/powerpc/platforms/powernv/npu-dma.c
> @@ -12,6 +12,7 @@
> #include <linux/export.h>
> #include <linux/pci.h>
> #include <linux/memblock.h>
> +#include <linux/iommu.h>
>
> #include <asm/iommu.h>
> #include <asm/pnv-pci.h>
> @@ -262,3 +263,128 @@ void pnv_npu_try_dma_set_bypass(struct pci_dev *gpdev, bool bypass)
> }
> }
> }
> +
> +long pnv_npu_set_window(struct pnv_ioda_pe *npe, int num,
> + struct iommu_table *tbl)
> +{
> + struct pnv_phb *phb = npe->phb;
> + int64_t rc;
> + const unsigned long size = tbl->it_indirect_levels ?
> + tbl->it_level_size : tbl->it_size;
> + const __u64 start_addr = tbl->it_offset << tbl->it_page_shift;
> + const __u64 win_size = tbl->it_size << tbl->it_page_shift;
> +
> + pe_info(npe, "Setting up window#%d %llx..%llx pg=%lx\n", num,
> + start_addr, start_addr + win_size - 1,
> + IOMMU_PAGE_SIZE(tbl));
> +
> + /* Ignore @num as there is just one window per NPU */
> + rc = opal_pci_map_pe_dma_window(phb->opal_id,
> + npe->pe_number,
> + npe->pe_number,
> + tbl->it_indirect_levels + 1,
> + __pa(tbl->it_base),
> + size << 3,
> + IOMMU_PAGE_SIZE(tbl));
> + if (rc) {
> + pe_err(npe, "Failed to configure TCE table, err %lld\n", rc);
> + return rc;
> + }
> +
> + pnv_pci_link_table_and_group(phb->hose->node, num,
> + tbl, &npe->table_group);
> + pnv_pci_ioda2_tce_invalidate_entire(npe->phb, false);
> +
> + return rc;
> +}
> +
> +long pnv_npu_unset_window(struct pnv_ioda_pe *npe, int num)
> +{
> + struct pnv_phb *phb = npe->phb;
> + long ret;
> +
> + pe_info(npe, "Removing DMA window #%d\n", num);
> +
> + /* Ignore @num as there is just one window per NPU */
> + ret = opal_pci_map_pe_dma_window(phb->opal_id, npe->pe_number,
> + npe->pe_number,
> + 0/* levels */, 0/* table address */,
> + 0/* table size */, 0/* page size */);
> + if (ret)
> + pe_warn(npe, "Unmapping failed, ret = %ld\n", ret);
> + else
> + pnv_pci_ioda2_tce_invalidate_entire(npe->phb, false);
> +
> + pnv_pci_unlink_table_and_group(npe->table_group.tables[num],
> + &npe->table_group);
> +
> + return ret;
> +}
> +
> +/* Switch ownership from platform code to external user (e.g. VFIO) */
> +void pnv_npu_take_ownership(struct pnv_ioda_pe *npe)
> +{
> + struct pnv_phb *phb = npe->phb;
> + int64_t ret;
> +
> + if (npe->table_group.tables[0]) {
> + /* Disable 32bit window */
> + pnv_pci_unlink_table_and_group(npe->table_group.tables[0],
> + &npe->table_group);
> + npe->table_group.tables[0] = NULL;
> + ret = opal_pci_map_pe_dma_window(phb->opal_id, npe->pe_number,
> + npe->pe_number,
> + 0/* levels */, 0/* table address */,
> + 0/* table size */, 0/* page size */);
> + } else {
> + /* Disable bypass */
> + ret = opal_pci_map_pe_dma_window_real(phb->opal_id,
> + npe->pe_number, npe->pe_number,
> + 0 /* bypass base */, 0);
> + }
It's not immediately obvious to me why this is an if/else. I'm
assuming that the way the kernel uses the NPE IOMMU it always either
has a 32-bit DMA window, or it's in bypass mode. Is that inherent to
the way the hardware works, or just the way Linux uses it?
I'm just worrying if this could open an exploitable hole if the host
kernel ever changes so that it could have bypass windows and TCE
windows simultaneously active. Is there any way to unconditionally
disable bypass *and* disable any existing DMA window.
Apart from that nit,
Reviewed-by: David Gibson <david@gibson.dropbear.id.au>
--
David Gibson | I'll have my music baroque, and my code
david AT gibson.dropbear.id.au | minimalist, thank you. NOT _the_ _other_
| _way_ _around_!
http://www.ozlabs.org/~dgibson
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 819 bytes --]
next prev parent reply other threads:[~2016-04-15 8:01 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-04-12 8:37 [PATCH kernel v3 0/9] powerpc/powernv/npu: Enable PCI pass through for NVLink Alexey Kardashevskiy
2016-04-12 8:37 ` [PATCH kernel v3 1/9] vfio/spapr: Relax the IOMMU compatibility check Alexey Kardashevskiy
2016-04-12 8:37 ` [PATCH kernel v3 2/9] powerpc/powernv: Rename pnv_pci_ioda2_tce_invalidate_entire Alexey Kardashevskiy
2016-04-12 8:37 ` [PATCH kernel v3 3/9] powerpc/powernv: Define TCE Kill flags Alexey Kardashevskiy
2016-04-12 8:37 ` [PATCH kernel v3 4/9] powerpc/powernv/npu: TCE Kill helpers cleanup Alexey Kardashevskiy
2016-04-12 8:37 ` [PATCH kernel v3 5/9] powerpc/powernv/npu: Use the correct IOMMU page size Alexey Kardashevskiy
2016-04-12 8:37 ` [PATCH kernel v3 6/9] powerpc/powernv/npu: Simplify DMA setup Alexey Kardashevskiy
2016-04-12 8:37 ` [PATCH kernel v3 7/9] powerpc/powernv/npu: Rework TCE Kill handling Alexey Kardashevskiy
2016-04-12 8:37 ` [PATCH kernel v3 8/9] powerpc/powernv/ioda2: Export debug helper pe_level_printk() Alexey Kardashevskiy
2016-04-12 8:37 ` [PATCH kernel v3 9/9] powerpc/powernv/npu: Enable NVLink pass through Alexey Kardashevskiy
2016-04-12 9:49 ` kbuild test robot
2016-04-15 4:40 ` David Gibson [this message]
2016-04-18 1:52 ` Alistair Popple
2016-04-19 1:31 ` Alexey Kardashevskiy
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=20160415044020.GK18218@voom.redhat.com \
--to=david@gibson.dropbear.id.au \
--cc=aik@ozlabs.ru \
--cc=alex.williamson@redhat.com \
--cc=alistair@popple.id.au \
--cc=benh@kernel.crashing.org \
--cc=dja@axtens.net \
--cc=gwshan@linux.vnet.ibm.com \
--cc=linuxppc-dev@lists.ozlabs.org \
--cc=ruscur@russell.cc \
/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).