On Sat, 18 Jul 2026 at 00:25, Richard Henderson <[email protected]> wrote: > > There is a memory_region_is_ram check later that > actually does that this was trying to do. > > Signed-off-by: Richard Henderson <[email protected]> > --- > target/arm/tcg/mte_helper.c | 11 ----------- > 1 file changed, 11 deletions(-) > > diff --git a/target/arm/tcg/mte_helper.c b/target/arm/tcg/mte_helper.c > index 997248bd57..6177dea842 100644 > --- a/target/arm/tcg/mte_helper.c > +++ b/target/arm/tcg/mte_helper.c > @@ -181,17 +181,6 @@ allocation_tag_mem_internal(CPUARMState *env, int > ptr_mmu_idx, > goto fini; > } > > - /* > - * If not backed by host ram, there is no tag storage: access unchecked. > - * This is probably a guest os bug though, so log it. > - */ > - if (unlikely(ret.flags & TLB_MMIO)) { > - qemu_log_mask(LOG_GUEST_ERROR, > - "Page @ 0x%" PRIx64 " indicates Tagged Normal memory " > - "but is not backed by host ram\n", ptr); > - goto fini; > - }
The memory_region_is_ram() check is on the MR we got back from looking up the tag addr in the tag address space (which should always be RAM unless the board code messed something up). That's not the same as this check, which is looking at how the physical address is backed. Does RAM being monitored by a plugin appear as the TLB_MMIO flag here, or is that some other flag? If it does appear as TLB_MMIO, that would be a reason not to make this check here. But in that case you need to adjust the logging on the !memory_region_is_ram() check below, because we will now wind up there for both the "board code error" case (address is backed by host RAM but there's no tag RAM for it) and the "guest error" cases (guest configured some MMIO-backed range as Tagged in the page tables). thanks -- PMM
