Re: armv7-m: tlb_set_page_full: Assertion failed

[Raphaël Poggi]

Hi Peter,

I actually found the problem but I didn't know how to reply to the thread
as I sent my email before being subscribed to the mailing list.

Anyway, you are right, the issue was that my base address wasn't aligned on 4k.
I said on my previous that base address was 0x0021E000 when in reality
it was 0x0021E004. Making the base address back to 0x0021E000 solved
the issue.

Thanks,
Raphael

Le sam. 30 mars 2024 à 14:53, Peter Maydell <peter.maydell@linaro.org> a écrit :
>
> On Fri, 29 Mar 2024 at 12:47, Raphaël Poggi <poggi.raph@gmail.com> wrote:
> >
> > Hi,
> >
> > I am currently working on adding support of a custom ASIC based on
> > ARMv7-M (Cortex-M3).
> >
> > I have a RAM region defined as followed:
> >
> > base address = 0x0021E000
> > size = 0x1FFC
> >
> > For some reason, during memcpy performed on guest side, I have an
> > assertion failed:
> >
> > qemu-system-arm: ../accel/tcg/cputlb.c:1169: tlb_set_page_full:
> > Assertion `!(iotlb & ~TARGET_PAGE_MASK)' failed.
> >
> > Here are some information I was able to gather during my debugging:
> > - my memcpy is the following:
> >
> > dest = 0x206006 (another ram region)
> > src = 0x21e008
> > size = 0x3f9
> >
> > - during the access that triggers the assertion, here are the state of
> > some variables just before the assertion:
> >
> > iotlb = 0xb03fc - ram_addr = 0xb0000 - xlat = 0x3fc - TARGET_PAGE_MASK
> > = 0xfffffc0
> >
> > - the last two lines of the gdb backtrace from qemu process:
> >
> > #4  0x0000555555de29fc in tlb_set_page_full
> >                               (cpu=cpu@entry=0x55555740c790,
> > mmu_idx=mmu_idx@entry=0x1, addr=addr@entry=0x21e400,
> > full=full@entry=0x7fffafffe010) at ../accel/tcg/cputlb.c:1169
> >
> > #5  0x0000555555d2b5fa in arm_cpu_tlb_fill
> >
> > (cs=0x55555740c790, address=0x21e400, size=<optimized out>,
> > access_type=MMU_DATA_LOAD, mmu_idx=0x1, probe=<optimized out>,
> > retaddr=0x7fffb004b3c5) at ../target/arm/tcg/tlb_helper.c:364
> >
> > I am really struggling to understand what is going wrong with my very
> > limited knowledge of qemu.
>
> Hard to say just from this. (a) Are you using current head-of-git QEMU?
> (b) Can you reproduce on a stock upstream QEMU which doesn't have
> your local changes?
>
> (I suspect you're running into issues related to that odd-sized
> RAM region. QEMU is a lot more efficient when RAM areas are a
> multiple of 4K and 4K aligned, and that's by far the more tested
> codepath. Funny sized and funny aligned RAM regions are supposed
> to work, but you're much more likely to run into bugs in that
> codepath.)
>
> thanks
> -- PMM