On Wed, Mar 30, 2022 at 4:16 PM Tian, Kevin <kevin.t...@intel.com> wrote: > > > 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.
3.0 should be fine, but I need to check whether there's another difference for PASID mode. It would be helpful if there's a chapter in the spec to describe the difference of behaviours. > > > > > 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? Red Hat supports vIOMMU for the guest DPDK path now. For scalable-mode we need to see some use cases then we can evaluate. virtio SVA could be a possible use case, but it requires more work e.g PRS queue. > If not, do we want to apply this version scheme only when it > reaches the production quality or also in the experimental phase? Yes. E.g if we think scalable mode is mature, we can enable 3.0. Thanks > > Thanks > Kevin