Closed just-for-fun-too closed 1 year ago
The STU is the smallest page size that the first or second stage page based virtual memory system mode selected for that device. The virtual memory system modes supported by the IOMMU are provided in the capabilities register. In case of RISC-V this is 4 KiB for all virtual memory system modes. Hence, as part of enabling ATS in a device connected to a host with a RISC-V IOMMU, the ATS control register should be programmed with a value of 0.
Whether an IOMMU supports returning multiple translations is implementation specific and the rules are specified by PCIe. The implementation may do one of the following for such requests:
Thank you very much for the answer regarding STU and also including the case of sending back multiple translations!
STU is programmed in the ATS Control register of IO devices (Functions) which support ATS requests. It can have a value from 0 to 31 indicating 1 to 2^31 4096-byte blocks.
The Untranslated Address Field in an ATS Translation Request has to be checked for validity against the implied (address) range to see if it is valid or not. This range is computed using the STU for that IO device using the formula 2^(STU+12) + (Length/2). Length is available in the Translation Request Header, and as such available to the IOMMU, but STU is not. Questions:
1- How does the IOMMU know the STU associated with an ATS request since, it is device specific, but no such field exists in the ATS request or the Device Context? 2- IS STU a fixed constant in the system? But there are no registers defined in the IOMMU to program it. 3- Can we use the custom field in the Translation control (tc) field of the Device Context to store a device specific STU.
Or am I missing something basic on how this check works.
Thanks
Thanks