RE: [PATCH v1 17/22] intel_iommu: do not pass down pasid bind for PASID #0

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



> From: Peter Xu <peterx@xxxxxxxxxx>
> Sent: Wednesday, March 25, 2020 11:12 PM
> 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 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>

thanks,

Regards,
Yi Liu




[Index of Archives]     [KVM ARM]     [KVM ia64]     [KVM ppc]     [Virtualization Tools]     [Spice Development]     [Libvirt]     [Libvirt Users]     [Linux USB Devel]     [Linux Audio Users]     [Yosemite Questions]     [Linux Kernel]     [Linux SCSI]     [XFree86]

  Powered by Linux