Re: [PATCH v5 02/25] iommu/sva: Manage process address spaces

["Christian König" <christian.koenig@amd.com>]

Am 20.04.20 um 13:55 schrieb Christoph Hellwig:
> On Mon, Apr 20, 2020 at 01:44:56PM +0200, Christian König wrote:
>> Am 20.04.20 um 10:10 schrieb Christoph Hellwig:
>>> On Mon, Apr 20, 2020 at 09:42:13AM +0200, Jean-Philippe Brucker wrote:
>>>> Right, I can see the appeal. I still like having a single mmu notifier per
>>>> mm because it ensures we allocate a single PASID per mm (as required by
>>>> x86). I suppose one alternative is to maintain a hashtable of mm->pasid,
>>>> to avoid iterating over all bonds during allocation.
>>> Given that the PASID is a pretty generic and important concept can
>>> we just add it directly to the mm_struct and allocate it lazily once
>>> we first need it?
>> Well the problem is that the PASID might as well be device specific. E.g.
>> some devices use 16bit PASIDs, some 15bit, some other only 12bit.
>>
>> So what could (at least in theory) happen is that you need to allocate
>> different PASIDs for the same process because different devices need one.
> This directly contradicts the statement from Jean-Philippe above that
> x86 requires a single PASID per mm_struct.  If we may need different
> PASIDs for different devices and can actually support this just
> allocating one per [device, mm_struct] would make most sense of me, as
> it doesn't couple otherwise disjoint state.

Well I'm not an expert on this topic. Felix can probably tell you a bit 
more about that.

Maybe it is sufficient to keep the allocated PASIDs as small as possible 
and return an appropriate error if a device can't deal with the 
allocated number.

If a device can only deal with 12bit PASIDs and more than 2^12 try to 
use it there isn't much else we can do than returning an error anyway.

Regards,
Christian.