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

Jerin Jacob Kollanukkaran jerinj at marvell.com
Tue Jul 23 16:36:26 CEST 2019


> -----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

> --
> Thanks,
> Anatoly


More information about the dev mailing list