> From: Jean-Philippe Brucker [mailto:jean-philippe.brucker@xxxxxxx] > Sent: Tuesday, August 22, 2017 10:19 PM > > On 22/08/17 07:24, Tian, Kevin wrote: > >>> (sorry to pick up this old thread, as the .tex one is not good for review > >>> and this thread provides necessary background for IOASID). > >>> > >>> Hi, Jean, > >>> > >>> I'd like to hear more clarification regarding the relationship between > >>> IOASID and PASID. When reading back above explanation, it looks > >>> confusing to me now (though I might get the meaning months ago :/). > >>> At least Intel VT-d only understands PASID (or you can think IOASID > >>> =PASID). There is no such layered address space concept. Then for > >>> map/unmap type request, do you intend to steal some PASIDs for > >>> that purpose on such architecture (since IOASID is a mandatory field > >>> in map/unmap request)? > >> > >> IOASID is a logical ID, it isn't used by hardware. The address space > >> concept in virtio-iommu allows to group endpoints together, so that they > >> have the same address space. I thought it was pretty much the same as > >> "domains" in VT-d? In any case, it is the same as domains in Linux. An > >> IOASID provides a handle for communication between virtio-iommu > device > >> and > >> driver, but unlike PASID, the IOASID number doesn't mean anything > outside > >> of virtio-iommu. > > > > Thanks. It's clear to me then. > > > > btw does it make more sense to use "domain id" instead of "IO address > > space id"? For one, when talking about layered address spaces > > usually parent address space is a superset of all child address spaces > > which doesn't apply to this case, since either anonymous address > > space or PASID-tagged address spaces are completely isolated. Instead> > 'domain' is a more inclusive terminology to embrace multiple address > > spaces. For two, 'domain' is better aligned to software terminology (e.g. > > iommu_domain) is easier for people to catch up. :-) > > I do agree that the naming isn't great. I didn't use "domain" for various > reasons (it also has a different meanings in ARM) but I keep regretting > it. As there is no virtio-iommu code upstream yet, it is still possible to > change this one. > > I find that "address space" was a good fit for the baseline device, but > the name doesn't scale. When introducing PASIDs, the address space > moves > one level down in the programming model. It is contexts, anonymous or > PASID-tagged, that should be called address spaces. I was considering > replacing it with "domain", "container", "partition"... > > Even though I don't want to use too much Linux terminology (virtio isn't > just Linux), "domain" is better fitted, somewhat neutral, and gets the > point across. A domain has one or more input address spaces and a single > output address space. > > When introducing nested translation to virtio-iommu (for the guest to have > virtual machines itself), there will be one or more intermediate address > spaces. Domains will be nested, with the terminology "parent domain" and > "child domain". I only briefly looked at a programming model for this but > I think we can nest virtio-iommus without much hassle. > > If there is no objection the next version will use "domain" in place of > "address_space". The change is quite invasive at this point, but I believe > that it will makes things more clear down the road. > Sounds good to me. Thanks.
