RE: [PATCH V2 1/4] intel-iommu: don't warn guest errors when getting rid2pasid entry

From: "Tian, Kevin" <kevin.tian@intel.com>
To: Jason Wang <jasowang@redhat.com>
Cc: "Liu, Yi L" <yi.l.liu@intel.com>,
	"yi.y.sun@linux.intel.com" <yi.y.sun@linux.intel.com>,
	"qemu-devel@nongnu.org" <qemu-devel@nongnu.org>,
	"peterx@redhat.com" <peterx@redhat.com>,
	"mst@redhat.com" <mst@redhat.com>
Subject: RE: [PATCH V2 1/4] intel-iommu: don't warn guest errors when getting rid2pasid entry
Date: Sat, 2 Apr 2022 07:33:56 +0000	[thread overview]
Message-ID: <BL1PR11MB5271E2D6268489B5475111E78CE39@BL1PR11MB5271.namprd11.prod.outlook.com> (raw)
In-Reply-To: <CACGkMEt9J6Jcy7+EmgFm-JTTqd82ONt_aOYRsxnTke2ZNSaA7A@mail.gmail.com>

> From: Jason Wang <jasowang@redhat.com>
> Sent: Wednesday, March 30, 2022 4:37 PM
> On Wed, Mar 30, 2022 at 4:16 PM Tian, Kevin <kevin.tian@intel.com> wrote:
> >
> > > From: Jason Wang <jasowang@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).
--

> 
> >
> > >
> > > 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.

Yes it's not ready for full evaluation yet.

The current state before your change is exactly feature-on-par with the
legacy mode, except using scalable format in certain structures. That alone
is not worthy of a formal evaluation.

> 
> > 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.
> 

Nice to know.

Thanks
Kevin