On Tue, Feb 3, 2026 at 10:24 AM Richard Henderson <[email protected]> wrote: > > On 2/2/26 17:53, Jim Shu wrote: > > Pass the access_type so that we could know CPU will do the read or > > write access. Then, CPU can fill the CPUTLBEntry[Full] of the specific > > permission (@prot). > > This is wrong. tlb_set_page* is recording data for *any* future translation. > There is no > one access_type which is appropriate. >
Thank you very much for reviewing this patchset! Considering the target MMU support in QEMU, I think tlb_set_page* can support RO/RW permission 'CPUTLBEntry[Full]' if the target MMU has RO/RW mappings. I have leveraged this idea to support cpu-side iommu translation. By using the access_type, we can do the following approach if the cpu-side IOMMU translation returns a different section in RO/WO iommu_flags: 1. When the CPU does read access, tlb_set_page* will create a RO CPUTLBEntry[Full] with read section & xlat_offset. 2. When the CPU does write access, tlb_set_page* will create a WO CPUTLBEntry[Full] with write section & xlat_offset. When the CPU does interleaved read and write accesses on IOMMUMemoryRegion, it probably has poor performance because It will get much TLB miss and go to the slow path create a CPUTLBEntry[Full] with another permission via tlb_set_page*. However, I think the functionality is correct. Do you think this approach has any possible issues? > I know you're trying to handle cpu-side iommu translation, and that you have > a case which > requires reads and writes to go to different address spaces (?), but this > doesn't help. > Yes, for our wgChecker case, reads and writes will go to different target_as, section and xlat_offset. When it has RO or WO permission, the success one will go to 'downstream_as' and failure one will go to 'blocked_io_as' > I think the underlying issue is that, for your case, we're handling iommu too > early -- we > want to be able to defer the translation until the actual access. > Currently, we handle the iommu translation early in the cpu-side. Thus, when IOMMUMemoryRegion changes the translation, we will rely on the IOMMUNotifier to trigger the tlb_flush() via TCGIOMMUNotifier to invalidate CPUTLBEntry. Then, next memory access will call the IOMMU translation function again in tlb_set_page* to find new translations. > r~ Thanks Jim
