RE: [PATCH V2 4/4] intel-iommu: PASID support

[Tian, Kevin]

> From: Jason Wang <jasowang@redhat.com>
> Sent: Wednesday, March 30, 2022 4:32 PM
> 
> >
> > >
> > > > If there is certain fault
> > > > triggered by a request with PASID, we do want to report this
> information
> > > > upward.
> > >
> > > I tend to do it increasingly on top of this series (anyhow at least
> > > RID2PASID is introduced before this series)
> >
> > Yes, RID2PASID should have been recorded too but it's not done correctly.
> >
> > If you do it in separate series, it implies that you will introduce another
> > "x-pasid-fault' to guard the new logic related to PASID fault recording?
> 
> Something like this, as said previously, if it's a real problem, it
> exists since the introduction of rid2pasid, not specific to this
> patch.
> 
> But I can add the fault recording if you insist.

I prefer to including the fault recording given it's simple and makes this
change more complete in concept. 😊

> > > >
> > > > Earlier when Yi proposed Qemu changes for guest SVA [1] he aimed for
> a
> > > > coarse-grained knob design:
> > > > --
> > > >   Intel VT-d 3.0 introduces scalable mode, and it has a bunch of
> capabilities
> > > >   related to scalable mode translation, thus there are multiple
> combinations.
> > > >   While this vIOMMU implementation wants simplify it for user by
> providing
> > > >   typical combinations. User could config it by "x-scalable-mode" 
> > > > option.
> > > The
> > > >   usage is as below:
> > > >     "-device intel-iommu,x-scalable-mode=["legacy"|"modern"]"
> > > >
> > > >     - "legacy": gives support for SL page table
> > > >     - "modern": gives support for FL page table, pasid, virtual command
> > > >     -  if not configured, means no scalable mode support, if not proper
> > > >        configured, will throw error
> > > > --
> > > >
> > > > Which way do you prefer to?
> > > >
> > > > [1] https://lists.gnu.org/archive/html/qemu-devel/2020-
> 02/msg02805.html
> > >
> > > My understanding is that, if we want to deploy Qemu in a production
> > > environment, we can't use the "x-" prefix. We need a full
> > > implementation of each cap.
> > >
> > > E.g
> > > -device intel-iommu,first-level=on,scalable-mode=on etc.
> > >
> >
> > You meant each cap will get a separate control option?
> >
> > But that way requires the management stack or admin to have deep
> > knowledge about how combinations of different capabilities work, e.g.
> > if just turning on scalable mode w/o first-level cannot support vSVA
> > on assigned devices. Is this a common practice when defining Qemu
> > parameters?
> 
> We can have a safe and good default value for each cap. E.g
> 
> In qemu 8.0 we think scalable is mature, we can make scalable to be
> enabled by default
> in qemu 8.1 we think first-level is mature, we can make first level to
> be enabled by default.
> 

OK, that is a workable way.

Thanks
Kevin