From: Alex Williamson <alex.williamson@redhat.com>
To: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Cc: Alexey Kardashevskiy <aik@ozlabs.ru>,
linuxppc-dev@lists.ozlabs.org,
David Gibson <david@gibson.dropbear.id.au>,
kvm-ppc@vger.kernel.org, Ram Pai <linuxram@us.ibm.com>,
kvm@vger.kernel.org, Alistair Popple <alistair@popple.id.au>
Subject: Re: [RFC PATCH kernel 0/5] powerpc/P9/vfio: Pass through NVIDIA Tesla V100
Date: Thu, 7 Jun 2018 18:34:17 -0600 [thread overview]
Message-ID: <20180607183417.3ff2acf1@w520.home> (raw)
In-Reply-To: <33590885d138195c8ede78b588ddb03b132267fd.camel@kernel.crashing.org>
On Fri, 08 Jun 2018 09:20:30 +1000
Benjamin Herrenschmidt <benh@kernel.crashing.org> wrote:
> On Thu, 2018-06-07 at 16:15 -0600, Alex Williamson wrote:
> > On Fri, 08 Jun 2018 07:54:02 +1000
> > Benjamin Herrenschmidt <benh@kernel.crashing.org> wrote:
> >
> > > On Thu, 2018-06-07 at 11:04 -0600, Alex Williamson wrote:
> > > >
> > > > Can we back up and discuss whether the IOMMU grouping of NVLink
> > > > connected devices makes sense? AIUI we have a PCI view of these
> > > > devices and from that perspective they're isolated. That's the view of
> > > > the device used to generate the grouping. However, not visible to us,
> > > > these devices are interconnected via NVLink. What isolation properties
> > > > does NVLink provide given that its entire purpose for existing seems to
> > > > be to provide a high performance link for p2p between devices?
> > >
> > > Not entire. On POWER chips, we also have an nvlink between the device
> > > and the CPU which is running significantly faster than PCIe.
> > >
> > > But yes, there are cross-links and those should probably be accounted
> > > for in the grouping.
> >
> > Then after we fix the grouping, can we just let the host driver manage
> > this coherent memory range and expose vGPUs to guests? The use case of
> > assigning all 6 GPUs to one VM seems pretty limited. (Might need to
> > convince NVIDIA to support more than a single vGPU per VM though)
> > Thanks,
>
> I don't know about "vGPUs" and what nVidia may be cooking in that area.
>
> The patched from Alexey allow for passing through the full thing, but
> they aren't trivial (there are additional issues, I'm not sure how
> covered they are, as we need to pay with the mapping attributes of
> portions of the GPU memory on the host side...).
>
> Note: The cross-links are only per-socket so that would be 2 groups of
> 3.
>
> We *can* allow individual GPUs to be passed through, either if somebody
> designs a system without cross links, or if the user is ok with the
> security risk as the guest driver will not enable them if it doesn't
> "find" both sides of them.
If GPUs are not isolated and we cannot prevent them from probing each
other via these links, then I think we have an obligation to configure
grouping in a way that doesn't rely on a benevolent userspace. Thanks,
Alex
next prev parent reply other threads:[~2018-06-08 0:34 UTC|newest]
Thread overview: 36+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-06-07 8:44 [RFC PATCH kernel 0/5] powerpc/P9/vfio: Pass through NVIDIA Tesla V100 Alexey Kardashevskiy
2018-06-07 8:44 ` [RFC PATCH kernel 1/5] vfio/spapr_tce: Simplify page contained test Alexey Kardashevskiy
2018-06-08 3:32 ` David Gibson
2018-06-07 8:44 ` [RFC PATCH kernel 2/5] powerpc/iommu_context: Change referencing in API Alexey Kardashevskiy
2018-06-07 8:44 ` [RFC PATCH kernel 3/5] powerpc/iommu: Do not pin memory of a memory device Alexey Kardashevskiy
2018-06-07 8:44 ` [RFC PATCH kernel 4/5] vfio_pci: Allow mapping extra regions Alexey Kardashevskiy
2018-06-07 17:04 ` Alex Williamson
2018-06-07 8:44 ` [RFC PATCH kernel 5/5] vfio_pci: Add NVIDIA GV100GL [Tesla V100 SXM2] [10de:1db1] subdriver Alexey Kardashevskiy
2018-06-07 17:04 ` Alex Williamson
2018-06-08 3:09 ` Alexey Kardashevskiy
2018-06-08 3:35 ` Alex Williamson
2018-06-08 3:52 ` Alexey Kardashevskiy
2018-06-08 4:34 ` Alex Williamson
2018-06-07 17:04 ` [RFC PATCH kernel 0/5] powerpc/P9/vfio: Pass through NVIDIA Tesla V100 Alex Williamson
2018-06-07 21:54 ` Benjamin Herrenschmidt
2018-06-07 22:15 ` Alex Williamson
2018-06-07 23:20 ` Benjamin Herrenschmidt
2018-06-08 0:34 ` Alex Williamson [this message]
2018-06-08 0:58 ` Benjamin Herrenschmidt
2018-06-08 1:18 ` Alex Williamson
2018-06-08 3:08 ` Alexey Kardashevskiy
2018-06-08 3:44 ` Alex Williamson
2018-06-08 4:14 ` Alexey Kardashevskiy
2018-06-08 5:03 ` Alex Williamson
2018-07-10 4:10 ` Alexey Kardashevskiy
2018-07-10 22:37 ` Alex Williamson
2018-07-11 9:26 ` Alexey Kardashevskiy
2018-07-30 8:58 ` Alexey Kardashevskiy
2018-07-30 16:29 ` Alex Williamson
2018-07-31 4:03 ` Alexey Kardashevskiy
2018-07-31 14:29 ` Alex Williamson
2018-08-01 8:37 ` Alexey Kardashevskiy
2018-08-01 16:16 ` Alex Williamson
2018-08-08 8:39 ` Alexey Kardashevskiy
2018-08-09 4:21 ` Alexey Kardashevskiy
2018-08-09 14:06 ` Alex Williamson
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=20180607183417.3ff2acf1@w520.home \
--to=alex.williamson@redhat.com \
--cc=aik@ozlabs.ru \
--cc=alistair@popple.id.au \
--cc=benh@kernel.crashing.org \
--cc=david@gibson.dropbear.id.au \
--cc=kvm-ppc@vger.kernel.org \
--cc=kvm@vger.kernel.org \
--cc=linuxppc-dev@lists.ozlabs.org \
--cc=linuxram@us.ibm.com \
/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).