From: Alex Williamson <alex.williamson@redhat.com>
To: Jike Song <albcamus@gmail.com>
Cc: "dev@dpdk.org" <dev@dpdk.org>
Subject: Re: [dpdk-dev] VFIO no-iommu
Date: Wed, 13 Jan 2016 23:52:29 -0700 [thread overview]
Message-ID: <1452754349.14628.10.camel@redhat.com> (raw)
In-Reply-To: <CANE52Kj6_10RtP75esvQVnkHOfpR9ekKdCH7uLsEy=LbpwsaYA@mail.gmail.com>
On Thu, 2016-01-14 at 14:03 +0800, Jike Song wrote:
> On Wed, Dec 16, 2015 at 12:38 PM, Alex Williamson
> <alex.williamson@redhat.com> wrote:
> >
> > So it works. Is it acceptable? Useful? Sufficiently complete? Does
> > it imply deprecating the uio interface? I believe the feature that
> > started this discussion was support for MSI/X interrupts so that VFs
> > can support some kind of interrupt (uio only supports INTx since it
> > doesn't allow DMA). Implementing that would be the ultimate test of
> > whether this provides dpdk with not only a more consistent interface,
> > but the feature dpdk wants that's missing in uio. Thanks,
> >
> Hi Alex,
>
> Sorry for jumping in. Just being curious, how does VFIO No-IOMMU mode
> support DMA from userspace drivers? If I understand correctly, due to
> the absence of IOMMU, pcidev has to use physaddr to start a DMA
> transaction, but how it is supposed to get physaddr from userspace
> drivers, /proc//pagemap or something else?
Hi Jike,
vfio no-iommu does nothing to facilitate DMA mappings, UIO didn't
either and DPDK managed to work with that. vfio no-iommu is meant to
be an enabler and provide a consistent vfio device model (with MSI/X
interrupts), but fundamentally the idea of a non-iommu protected, user
owned device capable of DMA is unsupportable. This is why vfio no-
iommu taints the kernel. With that in mind, one of the design goals is
to introduce as little code as possible for vfio no-iommu. A new vfio
iommu backend with pinning and virt-to-bus translation goes against
that design goal. I don't know the details of how DPDK did this with
UIO, but the same lack of DMA mapping facilities is present with vfio
no-iommu. It really just brings the vfio device model, nothing more.
Thanks,
Alex
next prev parent reply other threads:[~2016-01-14 6:52 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
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 [this message]
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=1452754349.14628.10.camel@redhat.com \
--to=alex.williamson@redhat.com \
--cc=albcamus@gmail.com \
--cc=dev@dpdk.org \
/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).