On Thu, Jan 21, 2016 at 4:02 PM, David Marchand <david.marchand at 6wind.com> wrote:
> Santosh, > > On Tue, Jan 19, 2016 at 7:57 PM, Santosh Shukla <sshukla at mvista.com> > wrote: > > Adding RTE_KDRV_VFIO_NOIOMMU mode in kernel driver. Also including > > rte_vfio_is_noiommu() helper function. This function will parse > > /sys/bus/pci/device/<bus_addr>/ and make sure that > > - vfio noiommu mode set in kernel driver > > - pci device attached to vfio-noiommu driver only > > > > If both condition satisfies then set drv->kdrv = RTE_KDRV_VFIO_NOIOMMU > > > > Also did similar changes in virtio_rd/wr, Changes applicable for virtio > spec > > 0.95 only. > > 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. > 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. > 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? > Regards, > -- > David Marchand >
