On Wed, Mar 25, 2020 at 10:42:25AM +0000, Liu, Yi L wrote: > > From: Peter Xu < peterx@xxxxxxxxxx> > > Sent: Wednesday, March 25, 2020 2:13 AM > > To: Liu, Yi L <yi.l.liu@xxxxxxxxx> > > 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@xxxxxxxxx> > > > Cc: Jacob Pan <jacob.jun.pan@xxxxxxxxxxxxxxx> > > > Cc: Peter Xu <peterx@xxxxxxxxxx> > > > Cc: Yi Sun <yi.y.sun@xxxxxxxxxxxxxxx> > > > Cc: Paolo Bonzini <pbonzini@xxxxxxxxxx> > > > Cc: Richard Henderson <rth@xxxxxxxxxxx> > > > Cc: Eduardo Habkost <ehabkost@xxxxxxxxxx> > > > Signed-off-by: Liu Yi L <yi.l.liu@xxxxxxxxx> > > > --- > > > 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@xxxxxxxxxx> -- Peter Xu
