On Sat, Apr 2, 2022 at 3:27 PM Tian, Kevin <kevin.t...@intel.com> wrote: > > > From: Jason Wang <jasow...@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. 😊
That's fine. Thanks > > > > > > > > > > > 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
