Messages in this thread | | | Subject | Re: [PATCH v3 02/16] iommu: Introduce cache_invalidate API | From | Auger Eric <> | Date | Tue, 14 May 2019 13:02:47 +0200 |
| |
Hi Jean,
On 5/14/19 12:42 PM, Jean-Philippe Brucker wrote: > On 14/05/2019 08:46, Auger Eric wrote: >> Hi Jean, >> >> On 5/13/19 7:09 PM, Jean-Philippe Brucker wrote: >>> On 13/05/2019 17:50, Auger Eric wrote: >>>>> struct iommu_inv_pasid_info { >>>>> #define IOMMU_INV_PASID_FLAGS_PASID (1 << 0) >>>>> #define IOMMU_INV_PASID_FLAGS_ARCHID (1 << 1) >>>>> __u32 flags; >>>>> __u32 archid; >>>>> __u64 pasid; >>>>> }; >>>> I agree it does the job now. However it looks a bit strange to do a >>>> PASID based invalidation in my case - SMMUv3 nested stage - where I >>>> don't have any PASID involved. >>>> >>>> Couldn't we call it context based invalidation then? A context can be >>>> tagged by a PASID or/and an ARCHID. >>> >>> I think calling it "context" would be confusing as well (I shouldn't >>> have used it earlier), since VT-d uses that name for device table >>> entries (=STE on Arm SMMU). Maybe "addr_space"? >> yes you're right. Well we already pasid table table terminology so we >> can use it here as well - as long as we understand what purpose it >> serves ;-) - So OK for iommu_inv_pasid_info. >> >> I think Jean understood we would keep pasid standalone field in I meant Jacob here. >> iommu_cache_invalidate_info's union. I understand the struct >> iommu_inv_pasid_info now would replace it, correct?
Thank you for the confirmation.
Eric
> > Yes > > Thanks, > Jean >
| |