Re: [PATCH] iommu: making IOMMU sysfs nodes API public

From: Alex Williamson
Date: Thu Feb 21 2013 - 23:11:45 EST

On Fri, 2013-02-22 at 11:04 +1100, David Gibson wrote:
> On Tue, Feb 19, 2013 at 01:11:51PM -0700, Alex Williamson wrote:
> > On Tue, 2013-02-19 at 18:38 +1100, David Gibson wrote:
> > > On Mon, Feb 18, 2013 at 10:24:00PM -0700, Alex Williamson wrote:
> > > > On Mon, 2013-02-18 at 17:15 +1100, Alexey Kardashevskiy wrote:
> [snip]
> > > > Adding the window size to sysfs seems more readily convenient,
> > > > but is it so hard for userspace to open the files and call a couple
> > > > ioctls to get far enough to call IOMMU_GET_INFO? I'm unconvinced the
> > > > clutter in sysfs more than just a quick fix. Thanks,
> > >
> > > And finally, as Alexey points out, isn't the point here so we know how
> > > much rlimit to give qemu? Using ioctls we'd need a special tool just
> > > to check the dma window sizes, which seems a bit hideous.
> >
> > Is it more hideous that using iommu groups to report a vfio imposed
> > restriction? Are a couple open files and a handful of ioctls worse than
> > code to parse directory entries and the future maintenance of an
> > unrestricted grab bag of sysfs entries?
> The fact that the memory is locked is a vfio restriction, but the
> actual dma window size is, genuinely, a property of the group.

A group is an association of devices based on isolation and visibility.
The dma window happens to be associated with a group on your platform,
but that's not always the case. This is why I was hoping something in
sysfs already reported the dma window so that we could point to it
rather than creating an interface where it doesn't really belong.


To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at
Please read the FAQ at