Re: [PATCH] accel/tcg: Complete cpu initialization before registration

[Eric Auger <eauger@redhat.com>]

Hi Peter,
On 2/2/23 11:53, Peter Maydell wrote:
> On Wed, 1 Feb 2023 at 20:37, Richard Henderson
> <richard.henderson@linaro.org> wrote:
>>
>> On 2/1/23 04:20, Eric Auger wrote:
>>> What I fail to understand is why this code is called with a kvm
>>> accelerated qemu (the test runs by default with kvm).
>> ...
>>> #2  0x000002aaab1500f0 in vmsa_ttbr_write
>>> (env=0x2aaac393850, ri=0x2aaac3c90e0, value=2154950976315703518) at
>>> ../target/arm/helper.c:3784
>>> #3  0x000002aaab14e5a8 in write_raw_cp_reg
>>> (env=env@entry=0x2aaac393850, ri=ri@entry=0x2aaac3c90e0,
>>> v=v@entry=2154950976315703518)
>>
>> This is indeed very curious -- vmsa_ttbr_write is supposed to be the "cooked" .writefn,
>> not the .raw_writefn.  We're not supposed to arrive here at all.
> 
> If you only provide a cooked .writefn and no .raw_writefn,
> the default is to assume that the cooked function will also
> work as the raw one. None of the ARMCPRegInfo structs that
> use vmsa_ttbr_write specify a raw_writefn...
I fail to understand. Do you suggest we miss explicit .raw_writefn =
raw_write in many places and that's the source of our trouble. Indeed
entering the TCG code in KVM mode looks weird.

Or is that supposed to work and we have a bug introduced by the abive
commit commit.

The backtrace of the sigsev shows:

Stack trace of thread 64909:
#0  0x0000aaaadb43ee4c tlb_flush_page_by_mmuidx_async_0 (qemu-kvm +
0x6aee4c)
#1  0x0000aaaadb0076a4 process_queued_cpu_work (qemu-kvm + 0x2776a4)
#2  0x0000aaaadb452ff8 kvm_vcpu_thread_fn (qemu-kvm + 0x6c2ff8)
#3  0x0000aaaadb591bf0 qemu_thread_start (qemu-kvm + 0x801bf0)
#4  0x0000ffff86382a28 start_thread (libc.so.6 + 0x82a28)
#5  0x0000ffff8632bb9c thread_start (libc.so.6 + 0x2bb9c)

Thanks

Eric

> 
> thanks
> -- PMM
>