| Message ID | 1584880579-12178-18-git-send-email-yi.l.liu@intel.com (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
| Series | intel_iommu: expose Shared Virtual Addressing to VMs | expand |
On Sun, Mar 22, 2020 at 05:36:14AM -0700, Liu Yi L wrote: > RID_PASID field was introduced in VT-d 3.0 spec, it is used > for DMA requests w/o PASID in scalable mode VT-d. It is also > known as IOVA. And in VT-d 3.1 spec, there is definition on it: > > "Implementations not supporting RID_PASID capability > (ECAP_REG.RPS is 0b), use a PASID value of 0 to perform > address translation for requests without PASID." > > This patch adds a check against the PASIDs which are going to be > bound to device. For PASID #0, it is not necessary to pass down > pasid bind request for it since PASID #0 is used as RID_PASID for > DMA requests without pasid. Further reason is current Intel vIOMMU > supports gIOVA by shadowing guest 2nd level page table. However, > in future, if guest IOMMU driver uses 1st level page table to store > IOVA mappings, then guest IOVA support will also be done via nested > translation. When gIOVA is over FLPT, then vIOMMU should pass down > the pasid bind request for PASID #0 to host, host needs to bind the > guest IOVA page table to a proper PASID. e.g PASID value in RID_PASID > field for PF/VF if ECAP_REG.RPS is clear or default PASID for ADI > (Assignable Device Interface in Scalable IOV solution). > > IOVA over FLPT support on Intel VT-d: > https://lkml.org/lkml/2019/9/23/297 > > Cc: Kevin Tian <kevin.tian@intel.com> > Cc: Jacob Pan <jacob.jun.pan@linux.intel.com> > Cc: Peter Xu <peterx@redhat.com> > Cc: Yi Sun <yi.y.sun@linux.intel.com> > Cc: Paolo Bonzini <pbonzini@redhat.com> > Cc: Richard Henderson <rth@twiddle.net> > Cc: Eduardo Habkost <ehabkost@redhat.com> > Signed-off-by: Liu Yi L <yi.l.liu@intel.com> > --- > hw/i386/intel_iommu.c | 10 ++++++++++ > 1 file changed, 10 insertions(+) > > diff --git a/hw/i386/intel_iommu.c b/hw/i386/intel_iommu.c > index 1e0ccde..b007715 100644 > --- a/hw/i386/intel_iommu.c > +++ b/hw/i386/intel_iommu.c > @@ -1886,6 +1886,16 @@ static int vtd_bind_guest_pasid(IntelIOMMUState *s, VTDBus *vtd_bus, > struct iommu_gpasid_bind_data *g_bind_data; > int ret = -1; > > + if (pasid < VTD_MIN_HPASID) { > + /* > + * If pasid < VTD_HPASID_MIN, this pasid is not allocated s/VTD_HPASID_MIN/VTD_MIN_HPASID/. > + * from host. No need to pass down the changes on it to host. > + * TODO: when IOVA over FLPT is ready, this switch should be > + * refined. What will happen if without this patch? Is it a must? > + */ > + return 0; > + } > + > vtd_dev_icx = vtd_bus->dev_icx[devfn]; > if (!vtd_dev_icx) { > return -EINVAL; > -- > 2.7.4 >
> From: Peter Xu < peterx@redhat.com> > Sent: Wednesday, March 25, 2020 2:13 AM > To: Liu, Yi L <yi.l.liu@intel.com> > Subject: Re: [PATCH v1 17/22] intel_iommu: do not pass down pasid bind for PASID > #0 > > On Sun, Mar 22, 2020 at 05:36:14AM -0700, Liu Yi L wrote: > > RID_PASID field was introduced in VT-d 3.0 spec, it is used for DMA > > requests w/o PASID in scalable mode VT-d. It is also known as IOVA. > > And in VT-d 3.1 spec, there is definition on it: > > > > "Implementations not supporting RID_PASID capability (ECAP_REG.RPS is > > 0b), use a PASID value of 0 to perform address translation for > > requests without PASID." > > > > This patch adds a check against the PASIDs which are going to be bound > > to device. For PASID #0, it is not necessary to pass down pasid bind > > request for it since PASID #0 is used as RID_PASID for DMA requests > > without pasid. Further reason is current Intel vIOMMU supports gIOVA > > by shadowing guest 2nd level page table. However, in future, if guest > > IOMMU driver uses 1st level page table to store IOVA mappings, then > > guest IOVA support will also be done via nested translation. When > > gIOVA is over FLPT, then vIOMMU should pass down the pasid bind > > request for PASID #0 to host, host needs to bind the guest IOVA page > > table to a proper PASID. e.g PASID value in RID_PASID field for PF/VF > > if ECAP_REG.RPS is clear or default PASID for ADI (Assignable Device > > Interface in Scalable IOV solution). > > > > IOVA over FLPT support on Intel VT-d: > > https://lkml.org/lkml/2019/9/23/297 > > > > Cc: Kevin Tian <kevin.tian@intel.com> > > Cc: Jacob Pan <jacob.jun.pan@linux.intel.com> > > Cc: Peter Xu <peterx@redhat.com> > > Cc: Yi Sun <yi.y.sun@linux.intel.com> > > Cc: Paolo Bonzini <pbonzini@redhat.com> > > Cc: Richard Henderson <rth@twiddle.net> > > Cc: Eduardo Habkost <ehabkost@redhat.com> > > Signed-off-by: Liu Yi L <yi.l.liu@intel.com> > > --- > > hw/i386/intel_iommu.c | 10 ++++++++++ > > 1 file changed, 10 insertions(+) > > > > diff --git a/hw/i386/intel_iommu.c b/hw/i386/intel_iommu.c index > > 1e0ccde..b007715 100644 > > --- a/hw/i386/intel_iommu.c > > +++ b/hw/i386/intel_iommu.c > > @@ -1886,6 +1886,16 @@ static int vtd_bind_guest_pasid(IntelIOMMUState *s, > VTDBus *vtd_bus, > > struct iommu_gpasid_bind_data *g_bind_data; > > int ret = -1; > > > > + if (pasid < VTD_MIN_HPASID) { > > + /* > > + * If pasid < VTD_HPASID_MIN, this pasid is not allocated > > s/VTD_HPASID_MIN/VTD_MIN_HPASID/. Got it. > > > + * from host. No need to pass down the changes on it to host. > > + * TODO: when IOVA over FLPT is ready, this switch should be > > + * refined. > > What will happen if without this patch? Is it a must? Before gIOVA is supported by nested translation, it is a must. This requires IOVA over 1st level page table is ready in guest kernel, also requires the QEMU/VFIO supports to bind the guest IOVA page table to host. Currently, guest kernel side is ready. However, QEMU and VFIO side is not. Regards, Yi Liu
On Wed, Mar 25, 2020 at 10:42:25AM +0000, Liu, Yi L wrote: > > From: Peter Xu < peterx@redhat.com> > > Sent: Wednesday, March 25, 2020 2:13 AM > > To: Liu, Yi L <yi.l.liu@intel.com> > > Subject: Re: [PATCH v1 17/22] intel_iommu: do not pass down pasid bind for PASID > > #0 > > > > On Sun, Mar 22, 2020 at 05:36:14AM -0700, Liu Yi L wrote: > > > RID_PASID field was introduced in VT-d 3.0 spec, it is used for DMA > > > requests w/o PASID in scalable mode VT-d. It is also known as IOVA. > > > And in VT-d 3.1 spec, there is definition on it: > > > > > > "Implementations not supporting RID_PASID capability (ECAP_REG.RPS is > > > 0b), use a PASID value of 0 to perform address translation for > > > requests without PASID." > > > > > > This patch adds a check against the PASIDs which are going to be bound > > > to device. For PASID #0, it is not necessary to pass down pasid bind > > > request for it since PASID #0 is used as RID_PASID for DMA requests > > > without pasid. Further reason is current Intel vIOMMU supports gIOVA > > > by shadowing guest 2nd level page table. However, in future, if guest > > > IOMMU driver uses 1st level page table to store IOVA mappings, then > > > guest IOVA support will also be done via nested translation. When > > > gIOVA is over FLPT, then vIOMMU should pass down the pasid bind > > > request for PASID #0 to host, host needs to bind the guest IOVA page > > > table to a proper PASID. e.g PASID value in RID_PASID field for PF/VF > > > if ECAP_REG.RPS is clear or default PASID for ADI (Assignable Device > > > Interface in Scalable IOV solution). > > > > > > IOVA over FLPT support on Intel VT-d: > > > https://lkml.org/lkml/2019/9/23/297 > > > > > > Cc: Kevin Tian <kevin.tian@intel.com> > > > Cc: Jacob Pan <jacob.jun.pan@linux.intel.com> > > > Cc: Peter Xu <peterx@redhat.com> > > > Cc: Yi Sun <yi.y.sun@linux.intel.com> > > > Cc: Paolo Bonzini <pbonzini@redhat.com> > > > Cc: Richard Henderson <rth@twiddle.net> > > > Cc: Eduardo Habkost <ehabkost@redhat.com> > > > Signed-off-by: Liu Yi L <yi.l.liu@intel.com> > > > --- > > > hw/i386/intel_iommu.c | 10 ++++++++++ > > > 1 file changed, 10 insertions(+) > > > > > > diff --git a/hw/i386/intel_iommu.c b/hw/i386/intel_iommu.c index > > > 1e0ccde..b007715 100644 > > > --- a/hw/i386/intel_iommu.c > > > +++ b/hw/i386/intel_iommu.c > > > @@ -1886,6 +1886,16 @@ static int vtd_bind_guest_pasid(IntelIOMMUState *s, > > VTDBus *vtd_bus, > > > struct iommu_gpasid_bind_data *g_bind_data; > > > int ret = -1; > > > > > > + if (pasid < VTD_MIN_HPASID) { > > > + /* > > > + * If pasid < VTD_HPASID_MIN, this pasid is not allocated > > > > s/VTD_HPASID_MIN/VTD_MIN_HPASID/. > > Got it. > > > > > > + * from host. No need to pass down the changes on it to host. > > > + * TODO: when IOVA over FLPT is ready, this switch should be > > > + * refined. > > > > What will happen if without this patch? Is it a must? > > Before gIOVA is supported by nested translation, it is a must. This requires > IOVA over 1st level page table is ready in guest kernel, also requires the > QEMU/VFIO supports to bind the guest IOVA page table to host. > Currently, guest kernel side is ready. However, QEMU and VFIO side is > not. OK: Reviewed-by: Peter Xu <peterx@redhat.com>
> From: Peter Xu <peterx@redhat.com> > Sent: Wednesday, March 25, 2020 11:12 PM > To: Liu, Yi L <yi.l.liu@intel.com> > Subject: Re: [PATCH v1 17/22] intel_iommu: do not pass down pasid bind for PASID > #0 > > On Wed, Mar 25, 2020 at 10:42:25AM +0000, Liu, Yi L wrote: > > > From: Peter Xu < peterx@redhat.com> > > > Sent: Wednesday, March 25, 2020 2:13 AM > > > To: Liu, Yi L <yi.l.liu@intel.com> > > > Subject: Re: [PATCH v1 17/22] intel_iommu: do not pass down pasid > > > bind for PASID > > > #0 > > > > > > On Sun, Mar 22, 2020 at 05:36:14AM -0700, Liu Yi L wrote: > > > > RID_PASID field was introduced in VT-d 3.0 spec, it is used for > > > > DMA requests w/o PASID in scalable mode VT-d. It is also known as IOVA. > > > > And in VT-d 3.1 spec, there is definition on it: > > > > > > > > "Implementations not supporting RID_PASID capability (ECAP_REG.RPS > > > > is 0b), use a PASID value of 0 to perform address translation for > > > > requests without PASID." > > > > > > > > This patch adds a check against the PASIDs which are going to be > > > > bound to device. For PASID #0, it is not necessary to pass down > > > > pasid bind request for it since PASID #0 is used as RID_PASID for > > > > DMA requests without pasid. Further reason is current Intel vIOMMU > > > > supports gIOVA by shadowing guest 2nd level page table. However, > > > > in future, if guest IOMMU driver uses 1st level page table to > > > > store IOVA mappings, then guest IOVA support will also be done via > > > > nested translation. When gIOVA is over FLPT, then vIOMMU should > > > > pass down the pasid bind request for PASID #0 to host, host needs > > > > to bind the guest IOVA page table to a proper PASID. e.g PASID > > > > value in RID_PASID field for PF/VF if ECAP_REG.RPS is clear or > > > > default PASID for ADI (Assignable Device Interface in Scalable IOV solution). > > > > > > > > IOVA over FLPT support on Intel VT-d: > > > > https://lkml.org/lkml/2019/9/23/297 > > > > > > > > Cc: Kevin Tian <kevin.tian@intel.com> > > > > Cc: Jacob Pan <jacob.jun.pan@linux.intel.com> > > > > Cc: Peter Xu <peterx@redhat.com> > > > > Cc: Yi Sun <yi.y.sun@linux.intel.com> > > > > Cc: Paolo Bonzini <pbonzini@redhat.com> > > > > Cc: Richard Henderson <rth@twiddle.net> > > > > Cc: Eduardo Habkost <ehabkost@redhat.com> > > > > Signed-off-by: Liu Yi L <yi.l.liu@intel.com> > > > > --- > > > > hw/i386/intel_iommu.c | 10 ++++++++++ > > > > 1 file changed, 10 insertions(+) > > > > > > > > diff --git a/hw/i386/intel_iommu.c b/hw/i386/intel_iommu.c index > > > > 1e0ccde..b007715 100644 > > > > --- a/hw/i386/intel_iommu.c > > > > +++ b/hw/i386/intel_iommu.c > > > > @@ -1886,6 +1886,16 @@ static int > > > > vtd_bind_guest_pasid(IntelIOMMUState *s, > > > VTDBus *vtd_bus, > > > > struct iommu_gpasid_bind_data *g_bind_data; > > > > int ret = -1; > > > > > > > > + if (pasid < VTD_MIN_HPASID) { > > > > + /* > > > > + * If pasid < VTD_HPASID_MIN, this pasid is not allocated > > > > > > s/VTD_HPASID_MIN/VTD_MIN_HPASID/. > > > > Got it. > > > > > > > > > + * from host. No need to pass down the changes on it to host. > > > > + * TODO: when IOVA over FLPT is ready, this switch should be > > > > + * refined. > > > > > > What will happen if without this patch? Is it a must? > > > > Before gIOVA is supported by nested translation, it is a must. This > > requires IOVA over 1st level page table is ready in guest kernel, also > > requires the QEMU/VFIO supports to bind the guest IOVA page table to host. > > Currently, guest kernel side is ready. However, QEMU and VFIO side is > > not. > > OK: > > Reviewed-by: Peter Xu <peterx@redhat.com> thanks, Regards, Yi Liu
diff --git a/hw/i386/intel_iommu.c b/hw/i386/intel_iommu.c index 1e0ccde..b007715 100644 --- a/hw/i386/intel_iommu.c +++ b/hw/i386/intel_iommu.c @@ -1886,6 +1886,16 @@ static int vtd_bind_guest_pasid(IntelIOMMUState *s, VTDBus *vtd_bus, struct iommu_gpasid_bind_data *g_bind_data; int ret = -1; + if (pasid < VTD_MIN_HPASID) { + /* + * If pasid < VTD_HPASID_MIN, this pasid is not allocated + * from host. No need to pass down the changes on it to host. + * TODO: when IOVA over FLPT is ready, this switch should be + * refined. + */ + return 0; + } + vtd_dev_icx = vtd_bus->dev_icx[devfn]; if (!vtd_dev_icx) { return -EINVAL;
RID_PASID field was introduced in VT-d 3.0 spec, it is used for DMA requests w/o PASID in scalable mode VT-d. It is also known as IOVA. And in VT-d 3.1 spec, there is definition on it: "Implementations not supporting RID_PASID capability (ECAP_REG.RPS is 0b), use a PASID value of 0 to perform address translation for requests without PASID." This patch adds a check against the PASIDs which are going to be bound to device. For PASID #0, it is not necessary to pass down pasid bind request for it since PASID #0 is used as RID_PASID for DMA requests without pasid. Further reason is current Intel vIOMMU supports gIOVA by shadowing guest 2nd level page table. However, in future, if guest IOMMU driver uses 1st level page table to store IOVA mappings, then guest IOVA support will also be done via nested translation. When gIOVA is over FLPT, then vIOMMU should pass down the pasid bind request for PASID #0 to host, host needs to bind the guest IOVA page table to a proper PASID. e.g PASID value in RID_PASID field for PF/VF if ECAP_REG.RPS is clear or default PASID for ADI (Assignable Device Interface in Scalable IOV solution). IOVA over FLPT support on Intel VT-d: https://lkml.org/lkml/2019/9/23/297 Cc: Kevin Tian <kevin.tian@intel.com> Cc: Jacob Pan <jacob.jun.pan@linux.intel.com> Cc: Peter Xu <peterx@redhat.com> Cc: Yi Sun <yi.y.sun@linux.intel.com> Cc: Paolo Bonzini <pbonzini@redhat.com> Cc: Richard Henderson <rth@twiddle.net> Cc: Eduardo Habkost <ehabkost@redhat.com> Signed-off-by: Liu Yi L <yi.l.liu@intel.com> --- hw/i386/intel_iommu.c | 10 ++++++++++ 1 file changed, 10 insertions(+)