New arm alignment issue with 6.2.0 - bisected to single revision

New arm alignment issue with 6.2.0 - bisected to single revision

[Mark Watson]

[-- Attachment #1: Type: text/plain, Size: 1249 bytes --]

Hi,

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

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.

Thanks,

Mark

[-- Attachment #2: Type: text/html, Size: 1697 bytes --]

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

[Peter Maydell]

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.
>


thanks
-- PMM

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

[Mark Watson]

[-- Attachment #1: Type: text/plain, Size: 974 bytes --]

On Thu, 6 Jan 2022 at 18:09, Peter Maydell <peter.maydell@linaro.org> 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) ?
>

I've just been trying but unfortunately do not yet have a simple enough
repro case to send. I have a custom machine which is backed by an fpga
version of the amiga hardware. It's somewhere fairly early in running the
amiga system rom. I'll keep trying to get something simple.

Thanks,

Mark

[-- Attachment #2: Type: text/html, Size: 1526 bytes --]

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

[Richard Henderson]

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~