> From: Jason Wang <jasow...@redhat.com> > Sent: Wednesday, April 6, 2022 11:33 AM > To: Tian, Kevin <kevin.t...@intel.com> > Cc: Liu, Yi L <yi.l....@intel.com>; m...@redhat.com; pet...@redhat.com; > yi.y....@linux.intel.com; qemu-devel@nongnu.org > Subject: Re: [PATCH V2 1/4] intel-iommu: don't warn guest errors when > getting rid2pasid entry > > On Sat, Apr 2, 2022 at 3:34 PM Tian, Kevin <kevin.t...@intel.com> wrote: > > > > > From: Jason Wang <jasow...@redhat.com> > > > Sent: Wednesday, March 30, 2022 4:37 PM > > > 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. > > > > There is a section called 'Revision History' in the start of the VT-d spec. > > It talks about changes in each revision, e.g.: > > -- > > June 2019, 3.1: > > > > Added support for RID-PASID capability (RPS field in ECAP_REG). > > Good to know that, does it mean, except for this revision history, all > the other semantics keep backward compatibility across the version?
Yes and if you find anything not clarified properly I can help forward to the spec owner. Thanks Kevin
