> From: Liu, Yi L <yi.l.liu@xxxxxxxxx> > Sent: Wednesday, November 6, 2024 5:23 PM > > On 2024/11/6 15:14, Tian, Kevin wrote: > >> From: Liu, Yi L <yi.l.liu@xxxxxxxxx> > >> Sent: Monday, November 4, 2024 9:19 PM > >> > >> As iommu driver is going to support pasid replacement, the new pasid > >> replace > >> helpers need to config the pasid entry as well. Hence, there are quite a > few > >> code to be shared with existing pasid setup helpers. This moves the pasid > >> config codes into helpers which can be used by existing pasid setup > helpers > >> and the future new pasid replace helpers. > > > > hmm probably you can add a link to the discussion which suggested > > to have separate replace/setup helpers. It's not intuitive to require > > this if just talking about "to support pasid replacement" > > this came from the offline chat with Baolu. He shared this idea to me > and it makes sense that we use pasid replace helpers instead of extending > the setup helpers. How about: > > This driver is going to support pasid replacement. A choice is to extend > the existing pasid setup helpers which is for creating a pasid entry. > However, it might change some assumption on the setup helpers. So adding > separate pasid replace helpers is chosen. Then we need to split the common > code that manipulate the pasid entry out from the setup helpers, hence it > can be used by the replace helpers as well. > Just put it simple e.g. "It is clearer to have a new set of pasid replacement helpers other than extending the existing ones to cover both initial setup and replacement. Then abstract out common code for manipulating the pasid entry as preparation."
