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 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).