Re: [Qemu-devel] Qemu deadlocks in tb_lock when using SVM+SoftMMU

[Richard Henderson <rth@twiddle.net>]

On 03/06/2017 08:32 AM, Alex Bennée wrote:
>> #5  0x000000000046ea2e in tlb_flush (cpu=0x164a360) at qemu.git/cputlb.c:121
>> #6  0x0000000000538987 in cpu_x86_update_cr4 (env=0x16525f0, new_cr4=1784)
>>     at qemu.git/target/i386/helper.c:660
>> #7  0x000000000055e318 in cpu_vmexit (env=0x16525f0, exit_code=78,
>> exit_info_1=4, retaddr=0)
>>     at qemu.git/target/i386/svm_helper.c:689
>> #8  0x000000000055d9b7 in cpu_svm_check_intercept_param (env=0x16525f0,
>> type=78, param=4, retaddr=0)
>>     at qemu.git/target/i386/svm_helper.c:511
>> #9  0x0000000000541acf in raise_interrupt2 (env=0x16525f0, intno=14,
>> is_int=0, error_code=4, next_eip_addend=0, retaddr=0)
>>     at qemu.git/target/i386/excp_helper.c:96
>> #10 0x0000000000541c0d in raise_exception_err_ra (env=0x16525f0,
>> exception_index=14, error_code=4, retaddr=0)
>>     at qemu.git/target/i386/excp_helper.c:127
>> #11 0x00000000005621a9 in tlb_fill (cs=0x164a360, addr=1245184,
>> access_type=MMU_INST_FETCH, mmu_idx=1, retaddr=0)
>>     at qemu.git/target/i386/mem_helper.c:212
> Richard,
>
> So this looks like another path through the SoftMMU code during
> code-generation (which is why tb_lock() is held in the first place). I'm
> not sure if the correct thing to do is bug out earlier or to defer the
> exception raising part to async work and exit the loop.

My guess is that everything from cpu_svm_check_intercept_param on should be 
done from do_interrupt instead of during raise_interrupt.


r~