On Fri, Sep 07, 2018 at 06:55:45PM +0100, Jean-Philippe Brucker wrote: > On 07/09/2018 17:53, Jerome Glisse wrote: > > So there is no reasons to do that under VFIO. Especialy as in your example > > it is not a real user space device driver, the userspace portion only knows > > about writting command into command buffer AFAICT. > > > > VFIO is for real userspace driver where interrupt, configurations, ... ie > > all the driver is handled in userspace. This means that the userspace have > > to be trusted as it could program the device to do DMA to anywhere (if > > IOMMU is disabled at boot which is still the default configuration in the > > kernel). > > If the IOMMU is disabled (not exactly a kernel default by the way, I > think most IOMMU drivers enable it by default), your userspace driver > can't bypass DMA isolation by accident. It just won't be allowed to > access the device. VFIO requires an IOMMU unless the admin forces the > NOIOMMU mode with the "enable_unsafe_noiommu_mode" module parameter, and > the userspace explicitly asks for it with VFIO_NOIOMMU_IOMMU, which > taints the kernel. Not for production. A normal userspace driver that > uses VFIO can only do DMA to its own memory. > Didn't know about VFIO check, which is a sane thing. On Intel IOMMU is disabled by default (see INTEL_IOMMU_DEFAULT_ON Kconfig option). I am pretty sure it use to be the same for AMD but maybe it is now enabled by default. Cheers, Jérôme
