Iommu/smmuv3 code analysis (10) page table operation

         From the front IOMMU DMA MAP/UNMAP API Call to know ,DMA MAP Whether it is dma_alloc_coherent() still dma_map_sg(), Finally call the function __iommu_map() function . It will calculate what needs to be mapped pgsize Page table size and count Number . When supported ops->map_pages when , Represents that multiple consecutive pages can be mapped at a time , This will call arm_lpae_map_pages(),SMMUv3 Support this method .

         about DMA UNMAP API, Whether it's dma_free_coherent(), still dma_unmap_sg(), The function will eventually be called __iommu_dma_unmap(), First of all, it is also acquisition unmap Of pgsize Page size and count Number , Then, according to whether it supports multiple pages unamp, Call page table unmap function , about SMMUv3, call arm_lpae_unamp_pages(), Finally, we need to TLB Invalidate the cache in .

1 A brief introduction to the page table

        SMMU Page table and MMU The page table of is the same , Will be in ARMv8-A Programming Guide to do a detailed introduction , This is only about ARM64 Some basic concepts of , It is easy to understand the code and the process of mapping and unmapping .

         Here we use 4K System as an example , stay 4K The page table size supported on the system is 4K/2M/1G. among level3 Page table item （ Become page The descriptor ） Point to 4K Size of memory page ,level2 Page table entries usually point to level3 Base address of page table entry （ At this time, the page table item is called table The descriptor ）, But it can also point directly to 2M Size of memory （ Page entries are called block The descriptor ）. The following figure gives a simple description of the three .

         in addition SMMU Page table properties of and CPU The properties of the page table are the same .

2 Initialization of page table

         stay SMMU And IO When the device is associated, it will be for each IO Equipment setup iommu_domain, In the final stage, it will establish a connection with the page table . By function alloc_io_pgtable_ops() and free_io_pgtable_ops() Allocate and release page tables .

         There are many page table formats , Such as 32 Bit LPAE,64 Bit LPAE, At the same time, they are divided into stage1 and stage2 The format of . This is only about ARM_64_LPAE_S1 namely 64 Bit LPAE Of stage1 Page table operation .

         A page table ARM_64_LPAE_S1 Distribution function of alloc_io_pgtable_ops() The callback will be called arm_64_lpae_alloc_pgtable_s1(), It assigns a structure for representing page table operations arm_lpae_io_pgtable, And fill in its callback functions, including map/map_pages/unmap/unmap_pages/iova_to_phys. These callback functions do the real mapping and unmapping of the page table . Later, we will focus on map_pages and unmap_pages. The other is to set the page table TCR and TTBR register , And assign PGD A page table （ Other levels of page tables are dynamically added and released ）.

         A page table ARM_64_LPAE_S1 The release function of free_io_pgtable_ops() Would call __arm_lpae_free_pgtable() Recursively release the page table level by level , And brush TLB.

3 Operation of page table

3.1 Mapping process of page table

         The mapping of the page table first passes through the function arm_lpae_prot_to_pte() Convert and set page table properties , And then through the function __arm_lpae_map() Search recursively at each level , And finally fill in the physical address in the finally found page table item , That is, create page table entries and point to the corresponding physical memory .

There are two situations here ：

1. When searching the table items of subordinate pages , No mapping has been established in the next level page table , That is, the current page table item points to NULL, At this time, you need to allocate the next level of page table entries , And point the current page table item to the allocated next level page table item , Go to the next level of search ;
2. When looking up entries in summer pages , If the next level page entry already exists , At this time, find the corresponding page table item in the next level page table item , Go to the next level of search ;

Here are the following figure examples to illustrate these two situations ：

         Set up two 4K Page mapping , The above situation is in level2 You can find the next level page table （ There should be other mappings before ）, Now find level3 The corresponding page table entry in , Just establish the mapping ;

         The following is level2 Point to the level3 The page table has not been established , At this time, you need to allocate physical memory to create a page table , And will level2 The page table entry of points to level3 Page table of .

3.2 Unmapping process of page table

         The unmapping process of the page table passes through the function arm_lpae_unmap_pages() Realization , It needs to find the corresponding page table entry , Clear page table , And carry on TLB To invalidate .

         Current level block Size and need unmap When the page size of is equal , It indicates that the corresponding mapping location is found , But there are also several situations ：

1. The current page table item is a non leaf node , This means that the next level belongs to the current mapping , At this time, you need to invalidate the next level page table , And release the physical page ;
2. The current page table item is a leaf node , This situation is block/page Page table , At this time, you can invalidate the leaf node page table entry ;

         Here are the following figures to illustrate these two situations ：

         Pictured above , need unmap The size is 2M size , So the size is the same as level2 Of block equal , Now find level2 The corresponding page table entry , In the above case , Page table entries are non leaf nodes , At this time, the next level page table pointed to is the mapping range that needs to be cancelled , At this time, you need to clear all page table entries of the next level page table , And carry on TLB To invalidate . In the following case , Page table items are leaf nodes , Point directly to a piece 2M Size of physical memory , At this time, clear the table items of the current page , And carry on TLB Just invalidate .

         In fact, there is another situation ： Although need unmap The page size of is the same as that of the current level block equal , But need unmap The size of needs to span two page tables , At this time, we need to separate the two parts unmap.

         Here is still a picture to illustrate ：

         In this case unmap The size of is still 2M, But not in level2 To represent , Instead, it spans two page entries , And each occupies 1M, At this moment in level3 There are two page tables corresponding to it , At this time, we need to deal with the first page table first , In the section dealing with the second page table .