On Thu, Oct 14, 2021 at 12:06:10PM -0300, Jason Gunthorpe wrote: > On Thu, Oct 14, 2021 at 03:33:21PM +1100, david@xxxxxxxxxxxxxxxxxxxxx wrote: > > > > If the HW can attach multiple non-overlapping IOAS's to the same > > > device then the HW is routing to the correct IOAS by using the address > > > bits. This is not much different from the prior discussion we had > > > where we were thinking of the PASID as an 80 bit address > > > > Ah... that might be a workable approach. And it even helps me get my > > head around multiple attachment which I was struggling with before. > > > > So, the rule would be that you can attach multiple IOASes to a device, > > as long as none of them overlap. The non-overlapping could be because > > each IOAS covers a disjoint address range, or it could be because > > there's some attached information - such as a PASID - to disambiguate. > > Right exactly - it is very parallel to PASID > > And obviously HW support is required to have multiple page table > pointers per RID - which sounds like PPC does (high/low pointer?) Hardware support is require *in the IOMMU*. Nothing (beyond regular 64-bit DMA support) is required in the endpoint devices. That's not true of PASID. > > What remains a question is where the disambiguating information comes > > from in each case: does it come from properties of the IOAS, > > propertues of the device, or from extra parameters supplied at attach > > time. IIUC, the current draft suggests it always comes at attach time > > for the PASID information. Obviously the more consistency we can have > > here the better. > > From a generic view point I'd say all are fair game. It is up to the > IOMMU driver to take the requested set of IOAS's, the "at attachment" > information (like PASID) and decide what to do, or fail. Ok, that's a model that makes sense to me. > > I can also see an additional problem in implementation, once we start > > looking at hot-adding devices to existing address spaces. > > I won't pretend to guess how to implement this :) Just from a modeling > perspective is something that works logically. If the kernel > implementation is too hard then PPC should do one of the other ideas. > > Personally I'd probably try for a nice multi-domain attachment model > like PASID and not try to create/destroy domains. I don't really follow what you mean by that. > As I said in my last email I think it is up to each IOMMU HW driver to > make these decisions, the iommufd framework just provides a > standardized API toward the attaching driver that the IOMMU HW must > fit into. > > Jason > -- David Gibson | I'll have my music baroque, and my code david AT gibson.dropbear.id.au | minimalist, thank you. NOT _the_ _other_ | _way_ _around_! http://www.ozlabs.org/~dgibson
Attachment:
signature.asc
Description: PGP signature
