On Wed 18-Jan-2017 7:55 AM, PX wrote: Hi, I have some questions about the SMMU on the new version of TK1 VMM as follows:
1. In the source code, smmu.c, the IO ASID 1 is assigned to hardware engine, AFI, which is supposed to connect with PCIE devices. However, when I add 1 to vm.smmu in vm.camkes, the VM can not access Ethernet and cause a SMMU translation error. But it works if I add 0 to vm.smmu as suggested by Kent. whats the reason to do so? The ASIDs assigned to the different SMMUs are purely of concern to the kernel, and their relationship with module ID numbering should be treated as coincidental. In the camkes VM when you write 'vm.smmu = [0];' you are requesting SMMU number 0, not 'the system mmu with the assigned I/O ASID of 0'. In this case when counting system MMUs from 0 the first one has module ID 1 and is the AFI SMMU. The fact that the implementation chose to assign it an I/O ASID of 1 should, as mentioned, be treated as a coincidence. 2. Each IO device is assigned with an IO space mapping. However, there is no IO ASID associated with these mappings. Does that means these mappings are associated with an IO ASID in the order given in vm.smmu? I may have answered what you were trying to ask with the previous question, if not please rephrase with what I have said about I/O ASIDs. 3. Is it possible for the VMM to change the IO mapping for a specific device? say, invalidate old mapping and load a new mapping? what's the rough idea to do so? In a previous e-mail I said
See the first three results from https://github.com/search?q=org%3ASEL4PROJ+CONFIG_ARM_SMMU&type=Code Essentially the vmm_guest_vspace_add_iospace function construction a regular vspace_t, but gives an iospace capability instead of a pagedirectory capability. After that all of the code that details with a 'normal' vspace works for an SMMU iospace and so what the guest_vspace.c code is doing is for any frame that is mapped into the guest (i.e. IPA->PA translation) it also calls the map function on each of the constructed vspace_t's, which adds the mapping to the iospace.
Aside from having a different root capability (an iospace cap vs. pd cap) the way to manipulate mappings is identical to a regular address space.
Adrian