Re: [PATCH 3/9] iommu: Introduce iommu do invalidate API function

[Joerg Roedel <joro@8bytes.org>]

On Wed, Jul 05, 2017 at 07:57:57AM +0000, Tian, Kevin wrote:
> > > struct tlb_invalidate_info
> > > {
> > >         __u32   model;  /* Vendor number */

I don't like to have a model-specifier here, as I don't think its
needed.

> > >         __u8 granularity
> > > #define DEVICE_SELECTVIE_INV    (1 << 0)
> > > #define PAGE_SELECTIVE_INV      (1 << 0)
> > > #define PASID_SELECTIVE_INV     (1 << 1)
> > >         __u32 pasid;
> > >         __u64 addr;
> > >         __u64 size;
> > >
> > >         /* Since IOMMU format has already been validated for this table,
> > >            the IOMMU driver knows that the following structure is in a
> > >            format it knows */
> > >         __u8 opaque[];
> > > };
> > >
> 
> I just gave some information in another thread:
> 
> https://lists.gnu.org/archive/html/qemu-devel/2017-07/msg00853.html
> 
> Below summarizes all the invalidation capabilities supported by Intel VTd:
> 
> Scope: All PASIDs, single PASID
> for each PASID:
>         all mappings, or page-selective mappings (addr, size)
> invalidation target:
>         IOTLB entries (leaf)
>         paging structure cache (non-leaf)
>         PASID cache (pasid->cr3)
> invalidation hint:
>         whether global pages are included
>         drain reads/writes

The AMD IOMMU for example supports similar flushing capabilities. They
are all based on a IOMMU-independent PCI standards (PASID, PRI, ATS),
and the interface can be designed around those standards instead of
IOMMU hardware implementations.

If a given hardware implementation does not support all of the above
flushing modes, it is always free to flush more than requested as
supported by its capabilities.

Regards,

	Joerg