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
_______________________________________________
iommu mailing list
[email protected]
https://lists.linuxfoundation.org/mailman/listinfo/iommu
