Messages in this thread |  | | Date | Wed, 26 Jul 2017 11:02:40 +0200 | From | Joerg Roedel <> | Subject | Re: [PATCH 3/9] iommu: Introduce iommu do invalidate API function |
| |
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
|  |