>-----Original Message-----
>From: Jason Wang <jasow...@redhat.com>
>Subject: Re: [PATCH] intel_iommu: Use the latest fault reasons defined by
>spec
>
>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.
Could you elaborate what we need to do for migration compatibility?
I see version is already exported so libvirt can query it, see:
DEFINE_PROP_UINT32("version", IntelIOMMUState, version, 0),
Thanks
Zhenzhong
>
>> 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
