On 07/16/19 18:59, Peter Maydell wrote:
> On Tue, 16 Jul 2019 at 17:51, Laszlo Ersek <[email protected]> wrote:
>> The issue still reproduces, so it makes sense for me to look at the host
>> kernel version... Well, I'm afraid it won't help much, for an upstream
>> investigation:
>>
>> 4.14.0-115.8.2.el7a.aarch64
>>
>> This is the latest released kernel from "Red Hat Enterprise Linux for
>> ARM 64 7".
>
> OK. (I'm using 4.15.0-51-generic from ubuntu).
>
> Could you run with QEMU under gdb, and when it hits the
> assertion go back up a stack frame to the arm_cpu_realizefn()
> frame, and then "print /x cpu->isar" ? That should show us
> what we think we've got as ID registers from the kernel.
> (You might need to build QEMU with --enable-debug to get
> useful enough debug info to do that, not sure.)
(My qemu build script always builds QEMU in two configs, the difference
being --prefix and --enable-debug.)
This is what I got:
(gdb) frame 4
#4 0x00000000006a063c in arm_cpu_realizefn (dev=0x1761140,
errp=0xffffffffe540)
at .../qemu/target/arm/cpu.c:1159
1159 assert(no_aa32 || cpu_isar_feature(arm_div, cpu));
(gdb) print /x cpu->isar
$1 = {id_isar0 = 0x0, id_isar1 = 0x0, id_isar2 = 0x0, id_isar3 = 0x0,
id_isar4 = 0x0, id_isar5 = 0x0, id_isar6 = 0x0, mvfr0 = 0x0,
mvfr1 = 0x0, mvfr2 = 0x0, id_aa64isar0 = 0x0, id_aa64isar1 = 0x0,
id_aa64pfr0 = 0x11, id_aa64pfr1 = 0x0, id_aa64mmfr0 = 0x0,
id_aa64mmfr1 = 0x0}
Thanks!
Laszlo
