>-----Original Message-----
>From: Jason Wang <jasow...@redhat.com>
>Subject: Re: [PATCH] intel_iommu: Use the latest fault reasons defined by
>spec
>
>On Tue, May 21, 2024 at 6:25 PM Duan, Zhenzhong
><zhenzhong.d...@intel.com> wrote:
>>
>>
>>
>> >-----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),
>
>It is the Qemu command line parameters not the version of the vmstate.
>
>For example -device intel-iommu,version=3.0
>
>Qemu then knows it should behave as 3.0.
So you want to bump vtd_vmstate.version?
In fact, this series change intel_iommu property from
x-scalable-mode=["on"|"off"]"
to x-scalable-mode=["legacy"|"modern"|"off"]".
My understanding management app should use same qemu cmdline
in source and destination, so compatibility is already guaranteed even if
we don't bump vtd_vmstate.version.
Thanks
Zhenzhong
