Re: [dpdk-dev] [PATCH v4 0/4] Fixes on IOVA mode selection

["Burakov, Anatoly" <anatoly.burakov@intel.com>]

On 23-Jul-19 2:56 PM, Burakov, Anatoly wrote:
> On 23-Jul-19 11:25 AM, Thomas Monjalon wrote:
>> 23/07/2019 11:57, Burakov, Anatoly:
>>> A machine without an IOMMU shouldn't have picked IOVA as VA in the first
>>> place. Perhaps this is something we could fix? I'm not sure how to
>>> detected that condition though, i don't think there's a mechanism to
>>> know that for sure. Some kernels create a "iommu" sysfs directories, but
>>> i'm not too sure if they're 1) there for older kernels we support, and
>>> 2) always there.
>> [..]
>>> On my machine, "/sys/devices/virtual/iommu" exists when IOMMU is
>>> enabled, but doesn't exist if it isn't ("/sys/class/iommu" exists in
>>> both cases, but is empty when IOMMU is disabled). Perhaps we could go
>>> off that?
>>
>> Yes, good idea.
>> We need to check how these sysfs entries are managed,
>> and how old they are by looking at Linux code history.
>>
> 
> Quick (and by no means thorough) Google reveals that IOMMU driver's 
> sysfs-related code dates back as far as kernel version 3.17:
> 
> https://elixir.bootlin.com/linux/v3.17.8/source/drivers/iommu/iommu-sysfs.c
> 
> I'm not a kernel code expert, but the code *looks* like it's creating an 
> IOMMU-related entry in sysfs. So, i take it we can be reasonably sure of 
> these entries' presence at least since v3.17 onwards? Do we support 
> kernels which don't have this code?
> 

After a short chat with Ferruh, i think we have even better way to 
determine whether IOMMU is enabled - the /sys/kernel/iommu filesystem. 
Those are created whenever it is possible for VFIO to run, even if VFIO 
driver itself is not loaded. These have been there since kernel 3.6, so 
our minimum requirements are met with this approach, i believe.

-- 
Thanks,
Anatoly