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-boun...@lists.linux-foundation.org
> [mailto:iommu-boun...@lists.linux-foundation.org] On Behalf Of Alex Williamson
> Sent: Saturday, October 10, 2015 12:11 AM
> To: alex.william...@redhat.com
> Cc: a...@scylladb.com; a...@cloudius-systems.com; g...@scylladb.com;
> m...@redhat.com; bruce.richard...@intel.com; cor...@lwn.net;
> linux-kernel@vger.kernel.org; alexander.du...@gmail.com;
> g...@cloudius-systems.com; step...@networkplumber.org;
> vl...@cloudius-systems.com; io...@lists.linux-foundation.org;
> h...@hansjkoch.de; gre...@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
> io...@lists.linux-foundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/iommu
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
