2016-01-21 16:43, Santosh Shukla: > David Marchand <david.marchand at 6wind.com> wrote: > > This is a mode (specific to vfio), not a new kernel driver. > > > Yes, Specific to VFIO and this is why noiommu appended after vfio i.e.. > __VFIO and __VFIO_NOIOMMU.
Woaaa! Your logic is really disappointing :) Specific to VFIO => append _NOIOMMU If it's for VFIO, it should be called VFIO (that's my logic). > > How come we need to distinguish between with/without iommu modes ? > > By default vfio framework assumes iommu i.,e., iommu present. Unless user > explicitly set "enable_unsafe_noiommu_mode" param. so in my opinion, we > care to parse vfio driver for _noiommu_ mode only. Why do we care to parse noiommu only? Even if virtio cannot work in an IOMMU case, there is no reason to add a VFIO_NOIOMMU type here. > > Should not vfio behave the same way from an api point of view ? > > > Yes It should. vfio gives similar file_ops i.e.. read/write/mmap/seek etc.. > I am little confused on your question, do you see any issue in vfio bar > rd/wr api implementation? I think you should just consider the VFIO API and let the noiommu option as a kernel configuration detail.
