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.
