Thread (18 messages) 18 messages, 3 authors, 2016-01-27

Re: [PATCH v6 08/11] eal: pci: introduce RTE_KDRV_VFIO_NOIOMMUi driver mode

From: Thomas Monjalon <hidden>
Date: 2016-01-21 11:29:35

2016-01-21 16:43, Santosh Shukla:
David Marchand [off-list ref] wrote:
quoted
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).
quoted
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.
quoted
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.
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help