On Wed, Apr 24, 2024 at 04:56:57PM +0000, Matthew Brost wrote: > > What "meta data" is there for a SVA mapping? The entire page table is > > an SVA. > > If we have allocated memory for GPU page tables in the range, This is encoded directly in the radix tree. > if range > has been invalidated, As I keep saying these ranges need sparsity, so you have to store per-page in the radix tree if it is invalidated. There should be no need for a per-range tracking. > notifier seqno, ? The mmu notifier infrastructure handles seqno. You need a mmu notifier someplace that covers that SVA, or fractionally covers it, but that is not tied to the PTEs. > what type of mapping this is (SVA, > BO, userptr, NULL)... Which is back to a whole "SVA" type "vma" that covers the entire GPU page table when you bind the mm in the first place. > > > structure, along with pages returned from hmm_range_fault, are used to > > > program the GPU PTEs. > > > > Most likely pages returned from hmm_range_fault() can just be stored > > directly in the page table's PTEs. I'd be surprised if you actually > > need seperate storage. (ignoring some of the current issues with the > > DMA API) > In theory that could work but again practice this not how it is done. > The "meta data" cover all the classes mapping mentioned above. Our PTE > programming code needs to be handle all the different requirements of > these specific classes in a single code path. Which is back to my first thesis, this is all about trying to bolt on an existing PTE scheme which is ill suited to the needs of SVA and hmm_range_fault. Jason
