On Fri, May 24, 2024 at 4:41 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 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?
Well, as I said, it's not a direct bumping.
>
> 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.
Exactly, so the point is to
vtd=3.0, the device works exactly as vtd spec 3.0.
vtd=3.3, the device works exactly as vtd spec 3.3.
When migration to the old qemu, mgmt can specify e.g vtd=3.0 for
backward migration compatibility.
Thanks
>
> Thanks
> Zhenzhong
