Re: [PULL 17/20] target/arm: Do memory type alignment check when translation disabled

[Peter Maydell <peter.maydell@linaro.org>]

On Mon, 27 May 2024 at 03:36, Richard Henderson
<richard.henderson@linaro.org> wrote:
>
> On 5/25/24 13:50, Bernhard Beschow wrote:
> >
> >
> > Am 25. Mai 2024 13:41:54 UTC schrieb Bernhard Beschow <shentey@gmail.com>:
> >>
> >>
> >> Am 5. März 2024 13:52:34 UTC schrieb Peter Maydell <peter.maydell@linaro.org>:
> >>> From: Richard Henderson <richard.henderson@linaro.org>
> >>>
> >>> If translation is disabled, the default memory type is Device, which
> >>> requires alignment checking.  This is more optimally done early via
> >>> the MemOp given to the TCG memory operation.
> >>>
> >>> Reviewed-by: Philippe Mathieu-Daudé <philmd@linaro.org>
> >>> Reported-by: Idan Horowitz <idan.horowitz@gmail.com>
> >>> Signed-off-by: Richard Henderson <richard.henderson@linaro.org>
> >>> Message-id: 20240301204110.656742-6-richard.henderson@linaro.org
> >>> Resolves: https://gitlab.com/qemu-project/qemu/-/issues/1204
> >>> Signed-off-by: Richard Henderson <richard.henderson@linaro.org>
> >>> Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
> >>
> >> Hi,
> >>
> >> This change causes an old 4.14.40 Linux kernel to panic on boot using the sabrelite machine:
> >>
> >> [snip]
> >> Alignment trap: init (1) PC=0x76f1e3d4 Instr=0x14913004 Address=0x76f34f3e FSR 0x001
> >> Alignment trap: init (1) PC=0x76f1e3d8 Instr=0x148c3004 Address=0x7e8492bd FSR 0x801
> >> Alignment trap: init (1) PC=0x76f0dab0 Instr=0x6823 Address=0x7e849fbb FSR 0x001
> >> Alignment trap: init (1) PC=0x76f0dab2 Instr=0x6864 Address=0x7e849fbf FSR 0x001
> >> scsi 0:0:0:0: Direct-Access     QEMU     QEMU HARDDISK    2.5+ PQ: 0 ANSI: 5
> >> fsl-asoc-card sound: ASoC: CODEC DAI sgtl5000 not registered
> >> imx-sgtl5000 sound: ASoC: CODEC DAI sgtl5000 not registered
> >> imx-sgtl5000 sound: snd_soc_register_card failed (-517)
> >> Alignment trap: init (1) PC=0x76eac95a Instr=0xf8dd5015 Address=0x7e849b05 FSR 0x001
> >> Alignment trap: not handling instruction f8dd5015 at [<76eac95a>]
> >> Unhandled fault: alignment exception (0x001) at 0x7e849b05
> >> pgd = 9c59c000
> >> [7e849b05] *pgd=2c552831, *pte=109eb34f, *ppte=109eb83f
> >> Kernel panic - not syncing: Attempted to kill init! exitcode=0x00000007
> >>
> >> ---[ end Kernel panic - not syncing: Attempted to kill init! exitcode=0x00000007
> >>
> >> As you can see, some alignment exceptions are handled by the kernel, the last one isn't. I added some additional printk()'s and traced it down to this location in the kernel: <https://github.com/torvalds/linux/blob/v4.14/arch/arm/mm/alignment.c#L762> which claims that ARMv6++ CPUs can handle up to word-sized unaligned accesses, thus no fixup is needed.
> >>
> >> I hope that this will be sufficient for a fix. Let me know if you need any additional information.
> >
> > I'm performing a direct kernel boot. On real hardware, a bootloader is involved which probably enables unaligned access. This may explain why it works there but not in QEMU any longer.
> >
> > To fix direct kernel boot, it seems as if the "built-in bootloader" would need to be adapted/extended [1]. Any ideas?
>
> I strongly suspect a kernel bug.  Either mmu disabled or attempting unaligned access on
> pages mapped as Device instead of Normal.

The MMU surely must be enabled by this point in guest boot.
This change doesn't affect whether we do alignment checks based
on SCTLR.A being set, so it's not a simple "the bootloader was
supposed to clear that and it didn't" (besides, A=0 means no
checks, so that's the default anyway). So the failure is kind
of weird.

-- PMM