> From: Jason Wang <jasow...@redhat.com> > Sent: Tuesday, March 29, 2022 12:52 PM > > > >>> > >>> Currently the implementation of vtd_ce_get_rid2pasid_entry() is also > >>> problematic. According to VT-d spec, RID2PASID field is effective only > >>> when ecap.rps is true otherwise PASID#0 is used for RID2PASID. I didn't > >>> see ecap.rps is set, neither is it checked in that function. It > >>> works possibly > >>> just because Linux currently programs 0 to RID2PASID... > >> > >> This seems to be another issue since the introduction of scalable mode. > > > > yes. this is not introduced in this series. The current scalable mode > > vIOMMU support was following 3.0 spec, while RPS is added in 3.1. Needs > > to be fixed. > > > Interesting, so this is more complicated when dealing with migration > compatibility. So what I suggest is probably something like: > > -device intel-iommu,version=$version > > Then we can maintain migration compatibility correctly. For 3.0 we can > go without RPS and 3.1 and above we need to implement RPS.
This is sensible. Probably a new version number is created only when it breaks compatibility with an old version, i.e. not necessarily to follow every release from VT-d spec. In this case we definitely need one from 3.0 to 3.1+ given RID2PASID working on a 3.0 implementation will trigger a reserved fault due to RPS not set on a 3.1 implementation. > > Since most of the advanced features has not been implemented, we may > probably start just from 3.4 (assuming it's the latest version). And all > of the following effort should be done for 3.4 in order to productize it. > Agree. btw in your understanding is intel-iommu in a production quality now? If not, do we want to apply this version scheme only when it reaches the production quality or also in the experimental phase? Thanks Kevin
