Is there any relationship between mtt pagesize and pte pagesize?

[rock-ifly]

Is there any relationship between mtt pagesize and pte pagesize?

      Let's use mtt pagesize as the size of the mtt leaf page, which is 1GB, or 2MB for mmtL2, and 4KB for mttL1.
      Though the Smmtt spec shows no relationship between the mtt pagesize and the pte pagesize, I doubt that if we should make sure that the mtt pagesize bigger than the pte pagesize in mtt structure construction process by the RDSM. That Keeping mtt_pagesize >= pte_pagesize seems a good choice.

       (1) if  **pte_pagesize > mtt_pagesize**, when we check the mtt sturcture, it will take a few rounds the get the final results, since each just check a part of the page memory.
       (2) if **pte_pagesize <= mtt_pagesize**, just one round to search the mtt attribute from the mtt structure, this improve the system performace.
       (3) The RDSM can resolve the problem, and keep  mtt_pagesize >= pte_pagesize.
             (3.1)  A GuestOS in a TVM1 (sdid=1) demands a pte with the size of pte_pagesize, and the TSM send the memory request with  the size of pte_pagesize to the VMM(sdid=0)
             (3.2)  The VMM(sdid=0) allocates the memory PA with size of pte_pagesize, and convert it into the TVM1 by the TSM. In the TVM1, GuestOS, A pte entry is got with  VA-PA, pte_pagesize
             (3.3)  The RDSM update the mtt0(sdid=0) and mtt1(sdid=1). At this time, the RDSM knows the size the PA is pte_pagesize, and it should build a mtt entry with the size bigger or equal than the pte_pagesize. It is unreasonalbe to build a mtt entry with the size smaller than the pte_pagesize.
             (3.4)  mfence.spa to flush all the mttCache, to synchronize the mtt structure update.
             (3.5)  sfence.vma to flush all the tlbCache, to synchronize the tlb entry, since the VA-PA relationship may be changed
             (3.6)  flush all the Cache in the PE, to synchronize all the data, including mtt structure data

    Shall the Smmtt will make this clear in the future specification? 

[SiFiveHolland]

It's not possible to guarantee mtt_pagesize >= pte_pagesize. Supervisor software is allowed to map memory that it cannot access, or can only partially access. If hardware wants to use the same structure to cache page table walks and MTT walks, it is responsible for splitting entries to the appropriate granularity.

Take for example the hosting supervisor domain in a CoVE environment. It is running Linux, which uses large (2M/1G) pages for its direct map of DRAM. Say it allocates a 4k page of DRAM to a CoVE TVM. The RDSM will modify the MTT to deny access to that 4k page from the hosting supervisor domain, which may require splitting a larger region in the MTT. But the page table in Linux will not change, and will still have a 2M/1G page.

[rsahita]

@SiFiveHolland is exactly right - there is no architectural relationship between page sizes in 1st (or G-stage) page sizes and the MTT page sizes. The hardware managing the caches (and if any combined TLBs implemented) are responsible for splitting entries to the appropriate granularity when there is a big->small fracturing required. Also this is an important aspect of Smmtt that the MTT can overlay access restrictions on the mappings created by the supervisor domain kernel but cannot expand permissions. Similarly for any small->big page size conversions, it is upto the SW implementations to be able to optimize their use of caches and any TLB implementations.

[rsahita]

presuming ok to close this issue @rock-ifly

[rock-ifly]

ok，there is no architectural relationship between the two size.

Thanks you very much. @SiFiveHolland @rsahita