Re: [Qemu-devel] [PULL 08/10] target/arm: Conditionalize some asserts on aarch32 support

[Laszlo Ersek]

On 07/16/19 14:03, Peter Maydell wrote:
> On Fri, 24 May 2019 at 13:33, Laszlo Ersek <address@hidden> wrote:
>> On 11/02/18 18:16, Peter Maydell wrote:
>>> @@ -829,7 +840,7 @@ static void arm_cpu_realizefn(DeviceState *dev, Error 
>>> **errp)
>>>           * Presence of EL2 itself is ARM_FEATURE_EL2, and of the
>>>           * Security Extensions is ARM_FEATURE_EL3.
>>>           */
>>> -        assert(cpu_isar_feature(arm_div, cpu));
>>> +        assert(no_aa32 || cpu_isar_feature(arm_div, cpu));
>>
>> The assertion above fails on my AArch64 host (APM Mustang A3). Meaning
>> that my host CPU supports AArch32, but lacks "arm_div".
> 
> Hi; I just realized we left this assertion-failure bug report
> unaddressed, so I had a look at it.

Yes, it's also tracked under LP#1830864; thanks for looking into it.

> 
> I tried to repro on my Mustang, but this works for me.
> A CPU with AArch32 but without the Arm-mode division instructions
> would be non-compliant (and very obviously so if tested), so
> I suspect the actual problem is not with the hardware but with
> the kernel not correctly reporting the ID registers to QEMU.
> What kernel version are you using?

So, I've just retested, with the QEMU binary I've left around from last
time. (This QEMU binary was built at upstream commit d247c8e7f4fc, with
Phil's v2 series applied on top, for regression testing:

[PATCH v2 0/9] hw/block/pflash_cfi01: Add DeviceReset() handler

http://mid.mail-archive.com/address@hidden
)

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

Thanks!
Laszlo

>> Better yet: can we rework the code to emit a warning, rather than
>> aborting QEMU? Assertions are not the best tool IMHO for catching
>> unusual (or slightly non-conformant / early) hardware.)
> 
> The intention of the assertion really is to catch QEMU bugs
> where we got the ID register values wrong in our emulated
> CPUs. Perhaps we should relax all these assertions to only
> testing if we're using TCG, not KVM ?
> 
> thanks
> -- PMM
>