Hi Peter, On 2/2/23 11:53, Peter Maydell wrote: > On Wed, 1 Feb 2023 at 20:37, Richard Henderson > <richard.hender...@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 >
