I also think I begin to see some light too - I need to dig more to understand, but you opened my eye’s to something I didn’t check for - the memory listeners. And that could explain why we’re failing - there is an important detail I didn’t mention (I didn’t think it was important ;-) ) - as a result of the IOTLB translation, in that translation callback, we are adding memory regions. I suspect the result is a somewhat ’stale’ address map - as you say “flush might help”…. I need to check on that.
Anyway - THANKS ! (FWIW, if I can help at all with the re-factoring of the memory system, I’d love to. While I think the way SystemC does it is bad, I think standing back and recognising the lessons we've learned from QEMU, SystemC and indeed other systems could help guide us to a more utopian setup - perhaps - On my side, my intention is to look at the memory interface in a language and simulator agnostic fashion and try and come up with an interface that could be used across simulators and languages (e.g. Rust). This is no longer quite “pie in the sky”, there is now a proposal (which needs more work), but we’re making steps forward. But this isn’t really relevant to QEMU (yet)). Cheers Mark. > On 11 Dec 2025, at 21:14, Richard Henderson <[email protected]> > wrote: > > WARNING: This email originated from outside of Qualcomm. Please be wary of > any links or attachments, and do not enable macros. > > On 12/11/25 13:49, Mark Burton wrote: >> I am absolutely prepared to believe I’m handling the IOMMU incorrectly >> >> The setup I’m using is CPU->SMMU(TBU)->AddressSpace (totally unconnected >> from the CPU). >> >> What I see in the code is that the IOMMU is permitted to return an address >> space - that address space, in the cases I have, is totally unrelated to the >> CPU concerned. The CPU knows (till now), nothing about that address space. >> The address space being returned from the IOMMU translate doesn’t seem to be >> used - so I’m not overly surprised that we end up in the wrong place. >> Perhaps what you’re saying is that somehow we should be ‘registering’ this >> address space with (any?) CPU that could potentially get to it... >> >> What I see is that io_prepare calls down and gets the target_as from the >> IOMMU translate cb, but it only returns MemroyRegionSection, not the >> target_as, and then e.g. int_st_mmio_leN seems to use cpu->as and index’s >> from that ….. I don’t see what I can be missing? > > You're right that there's a disconnect. > > There's an initial translation in address_space_translate_for_iotlb() which > records a > MemoryRegionSection. Later, during execution, iotlb_to_section starts over > from the cpu > address space and tries to find the same MemoryRegionSection, but translation > is not involved. > > I suspect we need to revisit CPUTLBEntryFull.xlat_section, "indexing" of > MemoryRegionSection, etc. > > I've had in the back of my mind a reorg of the entire physical memory > subsystem, with an > eye toward eliminating TARGET_PAGE_SIZE entirely. The indexing nonsense > would must needs > change in that scenario. All very hand wavey at this point... > > > r~
