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

[Burakov, Anatoly]

On 23-Jul-19 3:36 PM, Jerin Jacob Kollanukkaran wrote:
>> -----Original Message-----
>> From: Burakov, Anatoly <anatoly.burakov at intel.com>
>> Sent: Tuesday, July 23, 2019 8:00 PM
>> To: Thomas Monjalon <thomas at monjalon.net>
>> Cc: Jerin Jacob Kollanukkaran <jerinj at marvell.com>; Stojaczyk, Dariusz
>> <dariusz.stojaczyk at intel.com>; David Marchand
>> <david.marchand at redhat.com>; dev at dpdk.org
>> Subject: [EXT] Re: [dpdk-dev] [PATCH v4 0/4] Fixes on IOVA mode selection
>> 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-sy
>>> sfs.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.
> 
> I can see /sys/kernel/iommu_groups/ on IOMMU systems not  /sys/kernel/iommu

Sorry, yes, a typo. It's /sys/kernel/iommu_groups/.

> 
>> --
>> Thanks,
>> Anatoly


-- 
Thanks,
Anatoly