From: Alex Williamson <alex.williamson@redhat.com>
To: Varun Sethi <Varun.Sethi@freescale.com>
Cc: "avi@scylladb.com" <avi@scylladb.com>,
"avi@cloudius-systems.com" <avi@cloudius-systems.com>,
"gleb@scylladb.com" <gleb@scylladb.com>,
"mst@redhat.com" <mst@redhat.com>,
"bruce.richardson@intel.com" <bruce.richardson@intel.com>,
"corbet@lwn.net" <corbet@lwn.net>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
"alexander.duyck@gmail.com" <alexander.duyck@gmail.com>,
"gleb@cloudius-systems.com" <gleb@cloudius-systems.com>,
"stephen@networkplumber.org" <stephen@networkplumber.org>,
"vladz@cloudius-systems.com" <vladz@cloudius-systems.com>,
"iommu@lists.linux-foundation.org"
<iommu@lists.linux-foundation.org>,
"hjk@hansjkoch.de" <hjk@hansjkoch.de>,
"gregkh@linuxfoundation.org" <gregkh@linuxfoundation.org>
Subject: Re: [RFC PATCH 0/2] VFIO no-iommu
Date: Sun, 11 Oct 2015 12:23:24 -0600 [thread overview]
Message-ID: <1444587804.4059.277.camel@redhat.com> (raw)
In-Reply-To: <BN1PR0301MB0627AEEF3B5B7E5FB87ECB29EA320@BN1PR0301MB0627.namprd03.prod.outlook.com>
On Sun, 2015-10-11 at 17:29 +0000, Varun Sethi wrote:
> Hi Alex,
> Thanks for the patch Alex. This would also require support in Qemu to expose the physical address to the VM. Are you looking at that part as well?
Quoting from below:
It should be obvious, but I always feel obligated to state that
this does not and will not ever enable device assignment to
virtual machines on non-IOMMU capable platforms.
I have no intention whatsoever, nor would I encourage or support use of
this mode for assignment to a virtual machine. VFIO has uses beyond
QEMU. Thanks,
Alex
> -----Original Message-----
> From: iommu-bounces@lists.linux-foundation.org [mailto:iommu-bounces@lists.linux-foundation.org] On Behalf Of Alex Williamson
> Sent: Saturday, October 10, 2015 12:11 AM
> To: alex.williamson@redhat.com
> Cc: avi@scylladb.com; avi@cloudius-systems.com; gleb@scylladb.com; mst@redhat.com; bruce.richardson@intel.com; corbet@lwn.net; linux-kernel@vger.kernel.org; alexander.duyck@gmail.com; gleb@cloudius-systems.com; stephen@networkplumber.org; vladz@cloudius-systems.com; iommu@lists.linux-foundation.org; hjk@hansjkoch.de; gregkh@linuxfoundation.org
> Subject: [RFC PATCH 0/2] VFIO no-iommu
>
> Recent patches for UIO have been attempting to add MSI/X support, which unfortunately implies DMA support, which users have been enabling anyway, but was never intended for UIO. VFIO on the other hand expects an IOMMU to provide isolation of devices, but provides a much more complete device interface, which already supports full MSI/X support. There's really no way to support userspace drivers with DMA capable devices without an IOMMU to protect the host, but we can at least think about doing it in a way that properly taints the kernel and avoids creating new code duplicating existing code, that does have a supportable use case.
>
> The diffstat is only so large because I moved vfio.c to vfio_core.c so I could more easily keep the module named vfio.ko while keeping the bulk of the no-iommu support in a separate file that can be optionally compiled. We're really looking at a couple hundred lines of mostly stub code. The VFIO_NOIOMMU_IOMMU could certainly be expanded to do page pinning and virt_to_bus() translation, but I didn't want to complicate anything yet.
>
> I've only compiled this and tested loading the module with the new no-iommu mode enabled, I haven't actually tried to port a DPDK driver to it, though it ought to be a pretty obvious mix of the existing UIO and VFIO versions (set the IOMMU, but avoid using it for mapping, use however bus translations are done w/ UIO). The core vfio device file is still /dev/vfio/vfio, but all the groups become /dev/vfio-noiommu/$GROUP.
>
> It should be obvious, but I always feel obligated to state that this does not and will not ever enable device assignment to virtual machines on non-IOMMU capable platforms.
>
> I'm curious what IOMMU folks think of this. This hack is really only possible because we don't use iommu_ops for regular DMA, so we can hijack it fairly safely. I believe that's intended to change though, so this may not be practical long term. Thanks,
>
> Alex
>
> ---
>
> Alex Williamson (2):
> vfio: Move vfio.c vfio_core.c
> vfio: Include no-iommu mode
>
>
> drivers/vfio/Kconfig | 15
> drivers/vfio/Makefile | 4
> drivers/vfio/vfio.c | 1640 ------------------------------------------
> drivers/vfio/vfio_core.c | 1680 +++++++++++++++++++++++++++++++++++++++++++
> drivers/vfio/vfio_noiommu.c | 185 +++++
> drivers/vfio/vfio_private.h | 31 +
> include/uapi/linux/vfio.h | 2
> 7 files changed, 1917 insertions(+), 1640 deletions(-) delete mode 100644 drivers/vfio/vfio.c create mode 100644 drivers/vfio/vfio_core.c create mode 100644 drivers/vfio/vfio_noiommu.c create mode 100644 drivers/vfio/vfio_private.h _______________________________________________
> iommu mailing list
> iommu@lists.linux-foundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/iommu
next prev parent reply other threads:[~2015-10-11 18:23 UTC|newest]
Thread overview: 21+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-10-09 18:40 [RFC PATCH 0/2] VFIO no-iommu Alex Williamson
2015-10-09 18:41 ` [RFC PATCH 1/2] vfio: Move vfio.c vfio_core.c Alex Williamson
2015-10-09 19:21 ` Greg KH
2015-10-09 18:41 ` [RFC PATCH 2/2] vfio: Include no-iommu mode Alex Williamson
2015-10-11 8:12 ` Avi Kivity
2015-10-11 8:57 ` Michael S. Tsirkin
2015-10-11 9:03 ` Avi Kivity
2015-10-11 9:19 ` Michael S. Tsirkin
2015-10-11 9:23 ` Gleb Natapov
2015-10-11 21:16 ` Alex Williamson
2015-10-12 15:56 ` Stephen Hemminger
2015-10-12 16:23 ` Alex Williamson
2015-10-12 16:31 ` Avi Kivity
2015-10-12 16:27 ` Michael S. Tsirkin
2015-10-12 17:46 ` Alex Williamson
2015-10-12 18:08 ` Alex Williamson
2015-10-11 17:29 ` [RFC PATCH 0/2] VFIO no-iommu Varun Sethi
2015-10-11 18:23 ` Alex Williamson [this message]
2015-10-11 18:28 ` Michael S. Tsirkin
2015-10-11 18:29 ` Michael S. Tsirkin
2015-10-11 19:25 ` 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=1444587804.4059.277.camel@redhat.com \
--to=alex.williamson@redhat.com \
--cc=Varun.Sethi@freescale.com \
--cc=alexander.duyck@gmail.com \
--cc=avi@cloudius-systems.com \
--cc=avi@scylladb.com \
--cc=bruce.richardson@intel.com \
--cc=corbet@lwn.net \
--cc=gleb@cloudius-systems.com \
--cc=gleb@scylladb.com \
--cc=gregkh@linuxfoundation.org \
--cc=hjk@hansjkoch.de \
--cc=iommu@lists.linux-foundation.org \
--cc=linux-kernel@vger.kernel.org \
--cc=mst@redhat.com \
--cc=stephen@networkplumber.org \
--cc=vladz@cloudius-systems.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