On Thu, Apr 28, 2022 at 03:58:30PM +1000, David Gibson wrote:
> On Thu, Mar 31, 2022 at 09:58:41AM -0300, Jason Gunthorpe wrote:
> > On Thu, Mar 31, 2022 at 03:36:29PM +1100, David Gibson wrote:
> >
> > > > +/**
> > > > + * struct iommu_ioas_iova_ranges - ioctl(IOMMU_IOAS_IOVA_RANGES)
> > > > + * @size: sizeof(struct iommu_ioas_iova_ranges)
> > > > + * @ioas_id: IOAS ID to read ranges from
> > > > + * @out_num_iovas: Output total number of ranges in the IOAS
> > > > + * @__reserved: Must be 0
> > > > + * @out_valid_iovas: Array of valid IOVA ranges. The array length is the smaller
> > > > + * of out_num_iovas or the length implied by size.
> > > > + * @out_valid_iovas.start: First IOVA in the allowed range
> > > > + * @out_valid_iovas.last: Inclusive last IOVA in the allowed range
> > > > + *
> > > > + * Query an IOAS for ranges of allowed IOVAs. Operation outside these ranges is
> > > > + * not allowed. out_num_iovas will be set to the total number of iovas
> > > > + * and the out_valid_iovas[] will be filled in as space permits.
> > > > + * size should include the allocated flex array.
> > > > + */
> > > > +struct iommu_ioas_iova_ranges {
> > > > + __u32 size;
> > > > + __u32 ioas_id;
> > > > + __u32 out_num_iovas;
> > > > + __u32 __reserved;
> > > > + struct iommu_valid_iovas {
> > > > + __aligned_u64 start;
> > > > + __aligned_u64 last;
> > > > + } out_valid_iovas[];
> > > > +};
> > > > +#define IOMMU_IOAS_IOVA_RANGES _IO(IOMMUFD_TYPE, IOMMUFD_CMD_IOAS_IOVA_RANGES)
> > >
> > > Is the information returned by this valid for the lifeime of the IOAS,
> > > or can it change? If it can change, what events can change it?
> > >
> > > If it *can't* change, then how do we have enough information to
> > > determine this at ALLOC time, since we don't necessarily know which
> > > (if any) hardware IOMMU will be attached to it.
> >
> > It is a good point worth documenting. It can change. Particularly
> > after any device attachment.
>
> Right.. this is vital and needs to be front and centre in the
> comments/docs here. Really, I think an interface that *doesn't* have
> magically changing status would be better (which is why I was
> advocating that the user set the constraints, and the kernel supplied
> or failed outright). Still I recognize that has its own problems.
That is a neat idea, it could be a nice option, it lets userspace
further customize the kernel allocator.
But I don't have a use case in mind? The simplified things I know
about want to attach their devices then allocate valid IOVA, they
don't really have a notion about what IOVA regions they are willing to
accept, or necessarily do hotplug.
What might be interesting is to have some option to load in a machine
specific default ranges - ie the union of every group and and every
iommu_domain. The idea being that after such a call hotplug of a
device should be very likely to succeed.
Though I don't have a user in mind..
> > I added this:
> >
> > * Query an IOAS for ranges of allowed IOVAs. Mapping IOVA outside these ranges
> > * is not allowed. out_num_iovas will be set to the total number of iovas and
> > * the out_valid_iovas[] will be filled in as space permits. size should include
> > * the allocated flex array.
> > *
> > * The allowed ranges are dependent on the HW path the DMA operation takes, and
> > * can change during the lifetime of the IOAS. A fresh empty IOAS will have a
> > * full range, and each attached device will narrow the ranges based on that
> > * devices HW restrictions.
>
> I think you need to be even more explicit about this: which exact
> operations on the fd can invalidate exactly which items in the
> information from this call? Can it only ever be narrowed, or can it
> be broadened with any operations?
I think "attach" is the phrase we are using for that operation - it is
not a specific IOCTL here because it happens on, say, the VFIO device FD.
Let's add "detatching a device can widen the ranges. Userspace should
query ranges after every attach/detatch to know what IOVAs are valid
for mapping."
> > > > +#define IOMMU_IOAS_COPY _IO(IOMMUFD_TYPE, IOMMUFD_CMD_IOAS_COPY)
> > >
> > > Since it can only copy a single mapping, what's the benefit of this
> > > over just repeating an IOAS_MAP in the new IOAS?
> >
> > It causes the underlying pin accounting to be shared and can avoid
> > calling GUP entirely.
>
> If that's the only purpose, then that needs to be right here in the
> comments too. So is expected best practice to IOAS_MAP everything you
> might want to map into a sort of "scratch" IOAS, then IOAS_COPY the
> mappings you actually end up wanting into the "real" IOASes for use?
That is one possibility, yes. qemu seems to be using this to establish
a clone ioas of an existing operational one which is another usage
model.
I added this additionally:
* This may be used to efficiently clone a subset of an IOAS to another, or as a
* kind of 'cache' to speed up mapping. Copy has an effciency advantage over
* establishing equivilant new mappings, as internal resources are shared, and
* the kernel will pin the user memory only once.
> Seems like it would be nicer for the interface to just figure it out
> for you: I can see there being sufficient complications with that to
> have this slightly awkward interface, but I think it needs a rationale
> to accompany it.
It is more than complicates, the kernel has no way to accurately know
when a user pointer is an alias of an existing user pointer or is
something new because the mm has become incoherent.
It is possible that uncoordinated modules in userspace could
experience data corruption if the wrong decision is made - mm
coherence with pinning is pretty weak in Linux.. Since I dislike that
kind of unreliable magic I made it explicit.
Thanks,
Jason
