From: Alex Williamson <alex.williamson@redhat.com>
To: "O'Driscoll, Tim" <tim.odriscoll@intel.com>,
Vincent JARDIN <vincent.jardin@6wind.com>,
"dev@dpdk.org" <dev@dpdk.org>
Subject: Re: [dpdk-dev] VFIO no-iommu
Date: Tue, 15 Dec 2015 09:53:18 -0700 [thread overview]
Message-ID: <1450198398.6042.32.camel@redhat.com> (raw)
In-Reply-To: <26FA93C7ED1EAA44AB77D62FBE1D27BA6747CE55@IRSMSX108.ger.corp.intel.com>
On Tue, 2015-12-15 at 13:43 +0000, O'Driscoll, Tim wrote:
> > -----Original Message-----
> > From: dev [mailto:dev-bounces@dpdk.org] On Behalf Of Alex
> > Williamson
> > Sent: Friday, December 11, 2015 11:03 PM
> > To: Vincent JARDIN; dev@dpdk.org
> > Subject: Re: [dpdk-dev] VFIO no-iommu
> >
> > On Fri, 2015-12-11 at 23:12 +0100, Vincent JARDIN wrote:
> > > Thanks Thomas for putting back this topic.
> > >
> > > Alex,
> > >
> > > I'd like to hear more about the impacts of "unsupported":
> > > https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/c
> > > ommi
> > > t/?id=033291eccbdb1b70ffc02641edae19ac825dc75d
> > > Use of this mode, specifically binding a device without a
> > > native
> > > IOMMU group to a VFIO bus driver will taint the kernel and
> > > should
> > > therefore not be considered supported.
> > >
> > > It means that we get ride of uio; so it is a nice code cleanup:
> > > but
> > > why
> > > would VFIO/NO IOMMU be better if the bottomline is "unsupported"?
> >
> > How supportable do you think the uio method is? Fundamentally we
> > have
> > a userspace driver doing unrestricted DMA; it can access and modify
> > any
> > memory in the system. This is the reason uio won't provide a
> > mechanism
> > to enable MSI and if you ask the uio maintainer, they don't support
> > DMA
> > at all, it's only intended as a programmed IO interface to the
> > device.
> > Unless we can sandbox a user owned device within an IOMMU
> > protected
> > container, it's not supportable. The VFIO no-iommu mode can simply
> > provide you that unsupported mode more easily since it leverages
> > code
> > from the supported mode, which is IOMMU protected. Thanks,
>
> Thanks for clarifying.
>
> This does seem like it would be useful for DPDK. We're doing some
> further investigation to see if it works out of the box with DPDK or
> if we need to make any changes to support it.
The iommu model is different, there's no type1 interface available when
using this mode since we have no ability to provide translation. The
no-iommu iommu model really does nothing, which is a possible issue for
userspace. Is it sufficient? We stopped short of creating a page
pinning interface through the no-iommu model because it requires code
and adding piles of new code for an interface we claim is unsupported
doesn't make a lot of sense. The device interface should be identical
to existing vfio support.
> Thomas highlighted that your original commit for this had been
> reverted. What specifically would you need from us in order to re-
> submit the VFIO No-IOMMU support?
No API changes should ever go into the kernel without being validated
by a user. Without that we're risking that the kernel interface is
broken and we're stuck supporting it. In this case I tried to make
sure we had a working user before it went it, gambled that it was close
enough to put in anyway, then paid the price when development went
silent on the user side. To get it back in, I'm going to need a
working use first. You can re-apply 033291eccbdb or re-
revert ae5515d66362 for development of that. I need to see that it
works and that there's some consensus from the dpdk community that it's
a worthwhile path forward for cases without an iommu. There's no point
in merging it if it only becomes a userspace proof of concept. Thanks,
Alex
next prev parent reply other threads:[~2015-12-15 16:53 UTC|newest]
Thread overview: 35+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-12-11 16:28 Thomas Monjalon
2015-12-11 22:12 ` Vincent JARDIN
2015-12-11 23:02 ` Alex Williamson
2015-12-15 13:43 ` O'Driscoll, Tim
2015-12-15 16:53 ` Alex Williamson [this message]
2015-12-16 4:04 ` Ferruh Yigit
2015-12-16 4:38 ` Alex Williamson
2015-12-16 8:35 ` Burakov, Anatoly
2015-12-16 16:23 ` Burakov, Anatoly
2015-12-16 23:17 ` Thomas Monjalon
2015-12-17 9:52 ` Burakov, Anatoly
2015-12-17 10:09 ` Thomas Monjalon
2015-12-17 19:38 ` Jan Viktorin
2015-12-17 21:16 ` Vincent JARDIN
2015-12-17 23:29 ` Stephen Hemminger
2015-12-16 17:11 ` Alex Williamson
2015-12-16 17:22 ` Burakov, Anatoly
2015-12-17 16:43 ` Alex Williamson
2015-12-18 10:43 ` Yigit, Ferruh
2015-12-18 14:38 ` Alex Williamson
2015-12-18 21:50 ` Alex Williamson
2015-12-21 11:46 ` Yigit, Ferruh
2015-12-21 12:18 ` [dpdk-dev] [PATCH] vfio: add no-iommu support Ferruh Yigit
2015-12-21 15:15 ` Burakov, Anatoly
2015-12-21 15:26 ` Yigit, Ferruh
2015-12-21 15:28 ` Burakov, Anatoly
2015-12-21 19:22 ` [dpdk-dev] VFIO no-iommu Alex Williamson
2015-12-22 20:20 ` Alex Williamson
2015-12-23 11:19 ` Burakov, Anatoly
2015-12-31 14:30 ` Santosh Shukla
2016-01-14 6:03 ` Jike Song
2016-01-14 6:52 ` Alex Williamson
2016-01-14 8:12 ` Jike Song
2015-12-11 23:20 ` Jan Viktorin
2015-12-15 11:20 ` Alejandro Lucero
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=1450198398.6042.32.camel@redhat.com \
--to=alex.williamson@redhat.com \
--cc=dev@dpdk.org \
--cc=tim.odriscoll@intel.com \
--cc=vincent.jardin@6wind.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).