qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-devel] tcg/translate-all.c:169: tb_lock: Assertion `!have_tb_l


From: Peter Maydell
Subject: Re: [Qemu-devel] tcg/translate-all.c:169: tb_lock: Assertion `!have_tb_lock' failed when doing cpu_restore_state in usermode
Date: Tue, 10 Oct 2017 12:07:06 +0100

On 10 October 2017 at 11:54, Alex Bennée <address@hidden> wrote:
>
> Peter Maydell <address@hidden> writes:
>
>> On 10 October 2017 at 10:53, Alex Bennée <address@hidden> wrote:
>>>
>>> Peter Maydell <address@hidden> writes:
>>>
>>>> Running the test program
>>>> http://people.linaro.org/~peter.maydell/thumb-over-page
>>>> (source at http://people.linaro.org/~peter.maydell/thumb-over-page.c)
>>>> in the usermode emulator:
>>>>  ./build/x86/arm-linux-user/qemu-arm
>>>> ~/linaro/qemu-misc-tests/thumb-over-page
>>>
>>> Does this fail when run via system mode as well?
>>
>> Nope, only usermode. (Makes sense, since the handle_cpu_signal()
>> codepath is only used in usermode emulation.)
>
> But surely system emulation has to deal with the same rolling over a
> page issue. How is it's resolution different?

In system emulation, the attempted load of code is via cpu_lduw_code(),
which in turn calls cpu_lduw_code_ra() passing it a retaddr parameter
of 0. This is then propagated through the softmmu functions until
it eventually reaches tlb_fill(), which then passes it to
cpu_restore_state() as the retaddr.

In usermode, we don't have the softmmu at all, so cpu_lduw_code()
turns into a straightforward host memory access, which is then
caught by the signal handler. The signal handler can't tell
whether it was invoked as a result of translated code or not,
so it just passes the PC of the host memory access to
cpu_restore_state(). cpu_restore_state() ought to check whether
the PC it is passed is within the TCG codegen buffer.

Incidentally cpu_restore_state currently says:
  /* A retaddr of zero is invalid so we really shouldn't have ended
   * up here.

but this isn't true -- it's an expected result for the case where
a zero retaddr was used, and we should deal with that in
cpu_restore_state() rather than making every caller do that test.

thanks
-- PMM



reply via email to

[Prev in Thread] Current Thread [Next in Thread]