From: Benjamin Herrenschmidt <benh@kernel.crashing.org>
To: Alexey Kardashevskiy <aik@ozlabs.ru>,
David Gibson <david@gibson.dropbear.id.au>
Cc: linuxppc-dev@lists.ozlabs.org,
Alistair Popple <alistair@popple.id.au>,
Daniel Axtens <dja@axtens.net>,
Gavin Shan <gwshan@linux.vnet.ibm.com>,
Paul Mackerras <paulus@samba.org>,
Russell Currey <ruscur@russell.cc>,
Alex Williamson <alex.williamson@redhat.com>
Subject: Re: [PATCH kernel 08/10] powerpc/powernv/npu: Add NPU devices to IOMMU group
Date: Tue, 22 Mar 2016 23:41:56 +1100 [thread overview]
Message-ID: <1458650516.3107.145.camel@kernel.crashing.org> (raw)
In-Reply-To: <56F0A46B.3040400@ozlabs.ru>
On Tue, 2016-03-22 at 12:48 +1100, Alexey Kardashevskiy wrote:
>
> I suppose GPU from guest1 could trigger DMA from NPU to guest2 memory.
> Which puts a constrain to management tools not to pass NPU without their
> GPU counterparts.
Management tools will not be taught such constraints. The plan always
was to make sure they are in the same group. So they should be.
> The host can be affected as bypass is not disabled on NPU when GPU is taken
> by VFIO, I'll fix this.
>
> >> If I put them to the same group as GPUs, I would have to have
> >> IODA2-linked-to-NPU bridge type with different iommu_table_group_ops or
> >> have multiple hacks everywhere in IODA2 to enable/disable bypass,
> >> etc.
> >
> > Well.. I suspect it would mean no longer having a 1:1 correspondance
> > between user-visible IOMMU groups and the internal iommu_table.
>
> Right.
They can share the table too ...
> Right now each GPU is sitting on a separate PHB and has its own PE. And all
> NPUs sit on a separate PHB and each couple of NPUs (2 links of the same
> GPU) gets a PE.
>
> So we have separate PEs (struct pnv_ioda_pe) already, each has its own
> iommu_table_group_ops with all these VFIO IOMMU callbacks. So to make this
> all appear as one IOMMU group in sysfs, I will need to stop embedding
> iommu_table_group into pnv_ioda_pe but make it a pointer with reference
> counting, etc. Quite a massive change...
Or you just put a quirk flag of some sort and a pointer to the "linked"
PE... sometimes that's a lot easier than lifting up the whole
infrastructure.
>
>
>
> >>>> ---
> >>>> arch/powerpc/platf
next prev parent reply other threads:[~2016-03-22 12:42 UTC|newest]
Thread overview: 26+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-03-09 6:28 [PATCH kernel 00/10] powerpc/powernv/npu: Enable PCI pass through for NVLink Alexey Kardashevskiy
2016-03-09 6:28 ` [PATCH kernel 01/10] vfio/spapr: Relax the IOMMU compatibility check Alexey Kardashevskiy
2016-03-10 5:35 ` David Gibson
2016-03-09 6:28 ` [PATCH kernel 02/10] powerpc/powernv: Rename pnv_pci_ioda2_tce_invalidate_entire Alexey Kardashevskiy
2016-03-10 5:35 ` David Gibson
2016-03-09 6:28 ` [PATCH kernel 03/10] powerpc/powernv: Define TCE Kill flags Alexey Kardashevskiy
2016-03-10 5:36 ` David Gibson
2016-03-09 6:29 ` [PATCH kernel 04/10] powerpc/powernv/npu: TCE Kill helpers cleanup Alexey Kardashevskiy
2016-03-10 5:42 ` David Gibson
2016-03-21 2:51 ` Alistair Popple
2016-03-09 6:29 ` [PATCH kernel 05/10] powerpc/powernv/npu: Use the correct IOMMU page size Alexey Kardashevskiy
2016-03-10 5:43 ` David Gibson
2016-03-21 2:57 ` Alistair Popple
2016-03-09 6:29 ` [PATCH kernel 06/10] powerpc/powernv/npu: Simplify DMA setup Alexey Kardashevskiy
2016-03-16 5:55 ` David Gibson
2016-03-21 3:59 ` Alistair Popple
2016-03-09 6:29 ` [PATCH kernel 07/10] powerpc/powernv/npu: Rework TCE Kill handling Alexey Kardashevskiy
2016-03-21 6:50 ` Alistair Popple
2016-03-09 6:29 ` [PATCH kernel 08/10] powerpc/powernv/npu: Add NPU devices to IOMMU group Alexey Kardashevskiy
2016-03-21 4:48 ` David Gibson
2016-03-21 8:25 ` Alexey Kardashevskiy
2016-03-22 0:25 ` David Gibson
2016-03-22 1:48 ` Alexey Kardashevskiy
2016-03-22 12:41 ` Benjamin Herrenschmidt [this message]
2016-03-09 6:29 ` [PATCH kernel 09/10] powerpc/powernv/ioda2: Export some helpers Alexey Kardashevskiy
2016-03-09 6:29 ` [PATCH kernel 10/10] powerpc/powernv/npu: Enable passing through via VFIO 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=1458650516.3107.145.camel@kernel.crashing.org \
--to=benh@kernel.crashing.org \
--cc=aik@ozlabs.ru \
--cc=alex.williamson@redhat.com \
--cc=alistair@popple.id.au \
--cc=david@gibson.dropbear.id.au \
--cc=dja@axtens.net \
--cc=gwshan@linux.vnet.ibm.com \
--cc=linuxppc-dev@lists.ozlabs.org \
--cc=paulus@samba.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.