qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: New arm alignment issue with 6.2.0 - bisected to single revision


From: Richard Henderson
Subject: Re: New arm alignment issue with 6.2.0 - bisected to single revision
Date: Sun, 6 Feb 2022 13:33:13 +1100
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101 Thunderbird/91.5.0

On 1/7/22 04:09, Peter Maydell wrote:
On Wed, 29 Dec 2021 at 20:15, Mark Watson <scrameta@googlemail.com> wrote:
I'm seeing a repeatable alignment exception running m68k system mode on armv7l 
(arm cortex a9) following this commit:
"fa947a667fceab02f9f85fc99f54aebcc9ae6b51 is the first bad commit
commit fa947a667fceab02f9f85fc99f54aebcc9ae6b51
Author: Richard Henderson <richard.henderson@linaro.org>
Date: Thu Jul 29 10:45:10 2021 -1000

hw/core: Make do_unaligned_access noreturn


cc'ing Richard as this was his commit. Do you have a repro case
(QEMU command line, any necessary files/images, etc) ?


While we may have had some thought of allowing system-mode
to return from this hook, we have no guests that require this.
"
With this included I see this in the kernel dmesg log:
[10621.993234] Alignment trap: not handling instruction f843b004 at [<b677bb2e>]
[10622.000479] 8<--- cut here ---
[10622.003609] Unhandled fault: alignment exception (0x811) at 0xb13eed96
[10622.010162] pgd = 45acdb93
[10622.012941] [b13eed96] *pgd=0557a831, *pte=c01ee743, *ppte=c01eec33

As well as bisecting I've verified it is this revision by checking out clean 
HEAD then reverting just this revision (+ fixing conflicts).

The patch itself just seems to be adding QEMU_NORETURN (aka '__attribute__ 
((__noreturn__))') which I'd expect to be benign, so I'm not really sure what 
is going on.

I cross-compiled it on Ubuntu using gcc/g++ (Ubuntu 9.3.0-17ubuntu1~20.04) 
9.3.0.

As far as I can see, m68k never generates alignment faults (do_unaligned_access is completely unimplemented), and never sets MO_ALIGN to require alignment on any memory operation.

It would be helpful to know what m68k guest insn has generated this fault...


r~




reply via email to

[Prev in Thread] Current Thread [Next in Thread]