[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: [PATCH v1 17/22] intel_iommu: do not pass down pasid bind for PASID
From: |
Liu, Yi L |
Subject: |
RE: [PATCH v1 17/22] intel_iommu: do not pass down pasid bind for PASID #0 |
Date: |
Wed, 25 Mar 2020 10:42:25 +0000 |
> From: Peter Xu < address@hidden>
> Sent: Wednesday, March 25, 2020 2:13 AM
> To: Liu, Yi L <address@hidden>
> 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 <address@hidden>
> > Cc: Jacob Pan <address@hidden>
> > Cc: Peter Xu <address@hidden>
> > Cc: Yi Sun <address@hidden>
> > Cc: Paolo Bonzini <address@hidden>
> > Cc: Richard Henderson <address@hidden>
> > Cc: Eduardo Habkost <address@hidden>
> > Signed-off-by: Liu Yi L <address@hidden>
> > ---
> > 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
- Re: [PATCH v1 08/22] vfio: init HostIOMMUContext per-container, (continued)
[PATCH v1 03/22] vfio: check VFIO_TYPE1_NESTING_IOMMU support, Liu Yi L, 2020/03/22
[PATCH v1 07/22] intel_iommu: add set/unset_iommu_context callback, Liu Yi L, 2020/03/22
[PATCH v1 17/22] intel_iommu: do not pass down pasid bind for PASID #0, Liu Yi L, 2020/03/22
[PATCH v1 11/22] intel_iommu: process PASID cache invalidation, Liu Yi L, 2020/03/22
[PATCH v1 02/22] header file update VFIO/IOMMU vSVA APIs, Liu Yi L, 2020/03/22
[PATCH v1 09/22] vfio/common: check PASID alloc/free availability, Liu Yi L, 2020/03/22
[PATCH v1 16/22] intel_iommu: replay pasid binds after context cache invalidation, Liu Yi L, 2020/03/22