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
