On Mon, May 20, 2024 at 12:15 PM Liu, Yi L <yi.l....@intel.com> wrote: > > > From: Duan, Zhenzhong <zhenzhong.d...@intel.com> > > Sent: Monday, May 20, 2024 11:41 AM > > > > > > > > >-----Original Message----- > > >From: Jason Wang <jasow...@redhat.com> > > >Sent: Monday, May 20, 2024 8:44 AM > > >To: Duan, Zhenzhong <zhenzhong.d...@intel.com> > > >Cc: qemu-devel@nongnu.org; Liu, Yi L <yi.l....@intel.com>; Peng, Chao P > > ><chao.p.p...@intel.com>; Yu Zhang <yu.c.zh...@linux.intel.com>; Michael > > >S. Tsirkin <m...@redhat.com>; Paolo Bonzini <pbonz...@redhat.com>; > > >Richard Henderson <richard.hender...@linaro.org>; Eduardo Habkost > > ><edua...@habkost.net>; Marcel Apfelbaum <marcel.apfelb...@gmail.com> > > >Subject: Re: [PATCH] intel_iommu: Use the latest fault reasons defined by > > >spec > > > > > >On Fri, May 17, 2024 at 6:26 PM Zhenzhong Duan > > ><zhenzhong.d...@intel.com> wrote: > > >> > > >> From: Yu Zhang <yu.c.zh...@linux.intel.com> > > >> > > >> Currently we use only VTD_FR_PASID_TABLE_INV as fault reason. > > >> Update with more detailed fault reasons listed in VT-d spec 7.2.3. > > >> > > >> Signed-off-by: Yu Zhang <yu.c.zh...@linux.intel.com> > > >> Signed-off-by: Zhenzhong Duan <zhenzhong.d...@intel.com> > > >> --- > > > > > >I wonder if this could be noticed by the guest or not. If yes should > > >we consider starting to add thing like version to vtd emulation code? > > > > Kernel only dumps the reason like below: > > > > DMAR: [DMA Write NO_PASID] Request device [20:00.0] fault addr 0x1234600000 > > [fault reason 0x71] SM: Present bit in first-level paging entry is clear > > Yes, guest kernel would notice it as the fault would be injected to vm. > > > Maybe bump 1.0 -> 1.1? > > My understanding version number is only informational and is far from > > accurate to mark if a feature supported. Driver should check cap/ecap > > bits instead. > > Should the version ID here be aligned with VT-d spec?
Probably, this might be something that could be noticed by the management to migration compatibility. > If yes, it should > be 3.0 as the scalable mode was introduced in spec 3.0. And the fault > code was redefined together with the introduction of this translation > mode. Below is the a snippet from the change log of VT-d spec. > > June 2018 3.0 > • Removed all text related to Extended-Mode. > • Added support for scalable-mode translation for DMA Remapping, that enables > PASIDgranular first-level, second-level, nested and pass-through translation > functions. > • Widen invalidation queue descriptors and page request queue descriptors > from 128 bits > to 256 bits and redefined page-request and page-response descriptors. > • Listed all fault conditions in a unified table and described DMA Remapping > hardware > behavior under each condition. Assigned new code for each fault condition in > scalablemode operation. > • Added support for Accessed/Dirty (A/D) bits in second-level translation. > • Added support for submitting commands and receiving response from virtual > DMA > Remapping hardware. > • Added a table on snooping behavior and memory type of hardware access to > various > remapping structures as appendix. > • Move Page Request Overflow (PRO) fault reporting from Fault Status register > (FSTS_REG) to Page Request Status register (PRS_REG). > > Regards. > Yi Liu Thanks
