* [Qemu-devel] [PATCH] mttcg: Set jmp_env to handle exit from tb_gen_code @ 2017-02-20 14:53 Pranith Kumar 2017-02-20 16:16 ` Alex Bennée 0 siblings, 1 reply; 7+ messages in thread From: Pranith Kumar @ 2017-02-20 14:53 UTC (permalink / raw) To: alex.bennee; +Cc: qemu-devel, rth tb_gen_code() can exit execution using cpu_exit_loop() when it cannot allocate new tb's. To handle this, we need to properly set the jmp_env pointer ahead of calling tb_gen_code(). CC:Alex Bennée <alex.bennee@linaro.org> CC: Richard Henderson <rth@twiddle.net> Signed-off-by: Pranith Kumar <bobby.prani@gmail.com> --- cpu-exec.c | 23 +++++++++++------------ 1 file changed, 11 insertions(+), 12 deletions(-) diff --git a/cpu-exec.c b/cpu-exec.c index 97d79612d9..4b70988b24 100644 --- a/cpu-exec.c +++ b/cpu-exec.c @@ -236,23 +236,22 @@ static void cpu_exec_step(CPUState *cpu) cpu_get_tb_cpu_state(env, &pc, &cs_base, &flags); tb_lock(); - tb = tb_gen_code(cpu, pc, cs_base, flags, - 1 | CF_NOCACHE | CF_IGNORE_ICOUNT); - tb->orig_tb = NULL; - tb_unlock(); - - cc->cpu_exec_enter(cpu); - if (sigsetjmp(cpu->jmp_env, 0) == 0) { + tb = tb_gen_code(cpu, pc, cs_base, flags, + 1 | CF_NOCACHE | CF_IGNORE_ICOUNT); + tb->orig_tb = NULL; + tb_unlock(); + + cc->cpu_exec_enter(cpu); /* execute the generated code */ trace_exec_tb_nocache(tb, pc); cpu_tb_exec(cpu, tb); - } + cc->cpu_exec_exit(cpu); - cc->cpu_exec_exit(cpu); - tb_lock(); - tb_phys_invalidate(tb, -1); - tb_free(tb); + tb_lock(); + tb_phys_invalidate(tb, -1); + tb_free(tb); + } tb_unlock(); } -- 2.11.0 ^ permalink raw reply related [flat|nested] 7+ messages in thread
* Re: [Qemu-devel] [PATCH] mttcg: Set jmp_env to handle exit from tb_gen_code 2017-02-20 14:53 [Qemu-devel] [PATCH] mttcg: Set jmp_env to handle exit from tb_gen_code Pranith Kumar @ 2017-02-20 16:16 ` Alex Bennée 2017-02-20 23:56 ` Pranith Kumar 0 siblings, 1 reply; 7+ messages in thread From: Alex Bennée @ 2017-02-20 16:16 UTC (permalink / raw) To: Pranith Kumar; +Cc: qemu-devel, rth Pranith Kumar <bobby.prani@gmail.com> writes: > tb_gen_code() can exit execution using cpu_exit_loop() when it cannot > allocate new tb's. To handle this, we need to properly set the jmp_env > pointer ahead of calling tb_gen_code(). > > CC:Alex Bennée <alex.bennee@linaro.org> > CC: Richard Henderson <rth@twiddle.net> > Signed-off-by: Pranith Kumar <bobby.prani@gmail.com> > --- > cpu-exec.c | 23 +++++++++++------------ > 1 file changed, 11 insertions(+), 12 deletions(-) > > diff --git a/cpu-exec.c b/cpu-exec.c > index 97d79612d9..4b70988b24 100644 > --- a/cpu-exec.c > +++ b/cpu-exec.c > @@ -236,23 +236,22 @@ static void cpu_exec_step(CPUState *cpu) > > cpu_get_tb_cpu_state(env, &pc, &cs_base, &flags); > tb_lock(); > - tb = tb_gen_code(cpu, pc, cs_base, flags, > - 1 | CF_NOCACHE | CF_IGNORE_ICOUNT); > - tb->orig_tb = NULL; > - tb_unlock(); > - > - cc->cpu_exec_enter(cpu); > - It occurs to me we are also diverging in our locking pattern from tb_find which takes mmap_lock first. This is a NOP for system emulation but needed for user-emulation (for which we can do cpu_exec_step but not cpu_exec_nocache). > if (sigsetjmp(cpu->jmp_env, 0) == 0) { > + tb = tb_gen_code(cpu, pc, cs_base, flags, > + 1 | CF_NOCACHE | CF_IGNORE_ICOUNT); > + tb->orig_tb = NULL; > + tb_unlock(); > + > + cc->cpu_exec_enter(cpu); > /* execute the generated code */ > trace_exec_tb_nocache(tb, pc); > cpu_tb_exec(cpu, tb); > - } > + cc->cpu_exec_exit(cpu); > > - cc->cpu_exec_exit(cpu); > - tb_lock(); > - tb_phys_invalidate(tb, -1); > - tb_free(tb); > + tb_lock(); > + tb_phys_invalidate(tb, -1); > + tb_free(tb); > + } > tb_unlock(); > } -- Alex Bennée ^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: [Qemu-devel] [PATCH] mttcg: Set jmp_env to handle exit from tb_gen_code 2017-02-20 16:16 ` Alex Bennée @ 2017-02-20 23:56 ` Pranith Kumar 2017-02-21 0:35 ` Alex Bennée 2017-02-21 15:04 ` Alex Bennée 0 siblings, 2 replies; 7+ messages in thread From: Pranith Kumar @ 2017-02-20 23:56 UTC (permalink / raw) To: Alex Bennée; +Cc: qemu-devel, rth Alex Bennée writes: > Pranith Kumar <bobby.prani@gmail.com> writes: > >> tb_gen_code() can exit execution using cpu_exit_loop() when it cannot >> allocate new tb's. To handle this, we need to properly set the jmp_env >> pointer ahead of calling tb_gen_code(). >> >> CC:Alex Bennée <alex.bennee@linaro.org> >> CC: Richard Henderson <rth@twiddle.net> >> Signed-off-by: Pranith Kumar <bobby.prani@gmail.com> >> --- >> cpu-exec.c | 23 +++++++++++------------ >> 1 file changed, 11 insertions(+), 12 deletions(-) >> >> diff --git a/cpu-exec.c b/cpu-exec.c >> index 97d79612d9..4b70988b24 100644 >> --- a/cpu-exec.c >> +++ b/cpu-exec.c >> @@ -236,23 +236,22 @@ static void cpu_exec_step(CPUState *cpu) >> >> cpu_get_tb_cpu_state(env, &pc, &cs_base, &flags); >> tb_lock(); >> - tb = tb_gen_code(cpu, pc, cs_base, flags, >> - 1 | CF_NOCACHE | CF_IGNORE_ICOUNT); >> - tb->orig_tb = NULL; >> - tb_unlock(); >> - >> - cc->cpu_exec_enter(cpu); >> - > > It occurs to me we are also diverging in our locking pattern from > tb_find which takes mmap_lock first. This is a NOP for system emulation > but needed for user-emulation (for which we can do cpu_exec_step but not > cpu_exec_nocache). Right. So we have to take the mmap_lock() before calling tb_gen_code(). However, this lock is released in the error path before calling cpu_loop_exit() if allocation of a new tb fails. The following is what I have after merging with the previous EXCP_ATOMIC handling patch. diff --git a/cpu-exec.c b/cpu-exec.c index a8e04bffbf..2bb3ba3672 100644 --- a/cpu-exec.c +++ b/cpu-exec.c @@ -228,6 +228,7 @@ static void cpu_exec_nocache(CPUState *cpu, int max_cycles, static void cpu_exec_step(CPUState *cpu) { + CPUClass *cc = CPU_GET_CLASS(cpu); CPUArchState *env = (CPUArchState *)cpu->env_ptr; TranslationBlock *tb; target_ulong cs_base, pc; @@ -235,16 +236,24 @@ static void cpu_exec_step(CPUState *cpu) cpu_get_tb_cpu_state(env, &pc, &cs_base, &flags); tb_lock(); - tb = tb_gen_code(cpu, pc, cs_base, flags, - 1 | CF_NOCACHE | CF_IGNORE_ICOUNT); - tb->orig_tb = NULL; - tb_unlock(); - /* execute the generated code */ - trace_exec_tb_nocache(tb, pc); - cpu_tb_exec(cpu, tb); - tb_lock(); - tb_phys_invalidate(tb, -1); - tb_free(tb); + if (sigsetjmp(cpu->jmp_env, 0) == 0) { + mmap_lock(); + tb = tb_gen_code(cpu, pc, cs_base, flags, + 1 | CF_NOCACHE | CF_IGNORE_ICOUNT); + tb->orig_tb = NULL; + mmap_unlock(); + tb_unlock(); + + cc->cpu_exec_enter(cpu); + /* execute the generated code */ + trace_exec_tb_nocache(tb, pc); + cpu_tb_exec(cpu, tb); + cc->cpu_exec_exit(cpu); + + tb_lock(); + tb_phys_invalidate(tb, -1); + tb_free(tb); + } tb_unlock(); } diff --git a/cpus.c b/cpus.c index 77bba08f9a..b39408b4b1 100644 --- a/cpus.c +++ b/cpus.c @@ -1347,6 +1347,11 @@ static void *qemu_tcg_rr_cpu_thread_fn(void *arg) if (r == EXCP_DEBUG) { cpu_handle_guest_debug(cpu); break; + } else if (r == EXCP_ATOMIC) { + qemu_mutex_unlock_iothread(); + cpu_exec_step_atomic(cpu); + qemu_mutex_lock_iothread(); + break; } } else if (cpu->stop) { if (cpu->unplug) { @@ -1457,6 +1462,10 @@ static void *qemu_tcg_cpu_thread_fn(void *arg) */ g_assert(cpu->halted); break; + case EXCP_ATOMIC: + qemu_mutex_unlock_iothread(); + cpu_exec_step_atomic(cpu); + qemu_mutex_lock_iothread(); default: /* Ignore everything else? */ break; -- Pranith ^ permalink raw reply related [flat|nested] 7+ messages in thread
* Re: [Qemu-devel] [PATCH] mttcg: Set jmp_env to handle exit from tb_gen_code 2017-02-20 23:56 ` Pranith Kumar @ 2017-02-21 0:35 ` Alex Bennée 2017-02-21 4:05 ` Pranith Kumar 2017-02-21 15:04 ` Alex Bennée 1 sibling, 1 reply; 7+ messages in thread From: Alex Bennée @ 2017-02-21 0:35 UTC (permalink / raw) To: Pranith Kumar; +Cc: qemu-devel, rth Pranith Kumar <bobby.prani@gmail.com> writes: > Alex Bennée writes: > >> Pranith Kumar <bobby.prani@gmail.com> writes: >> >>> tb_gen_code() can exit execution using cpu_exit_loop() when it cannot >>> allocate new tb's. To handle this, we need to properly set the jmp_env >>> pointer ahead of calling tb_gen_code(). >>> >>> CC:Alex Bennée <alex.bennee@linaro.org> >>> CC: Richard Henderson <rth@twiddle.net> >>> Signed-off-by: Pranith Kumar <bobby.prani@gmail.com> >>> --- >>> cpu-exec.c | 23 +++++++++++------------ >>> 1 file changed, 11 insertions(+), 12 deletions(-) >>> >>> diff --git a/cpu-exec.c b/cpu-exec.c >>> index 97d79612d9..4b70988b24 100644 >>> --- a/cpu-exec.c >>> +++ b/cpu-exec.c >>> @@ -236,23 +236,22 @@ static void cpu_exec_step(CPUState *cpu) >>> >>> cpu_get_tb_cpu_state(env, &pc, &cs_base, &flags); >>> tb_lock(); >>> - tb = tb_gen_code(cpu, pc, cs_base, flags, >>> - 1 | CF_NOCACHE | CF_IGNORE_ICOUNT); >>> - tb->orig_tb = NULL; >>> - tb_unlock(); >>> - >>> - cc->cpu_exec_enter(cpu); >>> - >> >> It occurs to me we are also diverging in our locking pattern from >> tb_find which takes mmap_lock first. This is a NOP for system emulation >> but needed for user-emulation (for which we can do cpu_exec_step but not >> cpu_exec_nocache). > > Right. So we have to take the mmap_lock() before calling > tb_gen_code(). However, this lock is released in the error path before calling > cpu_loop_exit() if allocation of a new tb fails. The following is what I have > after merging with the previous EXCP_ATOMIC handling patch. Hmm we are a start/end_exclusive() though so what could we be racing against that also wants the mmap_lock()? Could it be held by anything at this point as every user needs to be woken up? > > diff --git a/cpu-exec.c b/cpu-exec.c > index a8e04bffbf..2bb3ba3672 100644 > --- a/cpu-exec.c > +++ b/cpu-exec.c > @@ -228,6 +228,7 @@ static void cpu_exec_nocache(CPUState *cpu, int max_cycles, > > static void cpu_exec_step(CPUState *cpu) > { > + CPUClass *cc = CPU_GET_CLASS(cpu); > CPUArchState *env = (CPUArchState *)cpu->env_ptr; > TranslationBlock *tb; > target_ulong cs_base, pc; > @@ -235,16 +236,24 @@ static void cpu_exec_step(CPUState *cpu) > > cpu_get_tb_cpu_state(env, &pc, &cs_base, &flags); > tb_lock(); > - tb = tb_gen_code(cpu, pc, cs_base, flags, > - 1 | CF_NOCACHE | CF_IGNORE_ICOUNT); > - tb->orig_tb = NULL; > - tb_unlock(); > - /* execute the generated code */ > - trace_exec_tb_nocache(tb, pc); > - cpu_tb_exec(cpu, tb); > - tb_lock(); > - tb_phys_invalidate(tb, -1); > - tb_free(tb); > + if (sigsetjmp(cpu->jmp_env, 0) == 0) { > + mmap_lock(); > + tb = tb_gen_code(cpu, pc, cs_base, flags, > + 1 | CF_NOCACHE | CF_IGNORE_ICOUNT); > + tb->orig_tb = NULL; > + mmap_unlock(); > + tb_unlock(); > + > + cc->cpu_exec_enter(cpu); > + /* execute the generated code */ > + trace_exec_tb_nocache(tb, pc); > + cpu_tb_exec(cpu, tb); > + cc->cpu_exec_exit(cpu); > + > + tb_lock(); > + tb_phys_invalidate(tb, -1); > + tb_free(tb); > + } > tb_unlock(); > } > > diff --git a/cpus.c b/cpus.c > index 77bba08f9a..b39408b4b1 100644 > --- a/cpus.c > +++ b/cpus.c > @@ -1347,6 +1347,11 @@ static void *qemu_tcg_rr_cpu_thread_fn(void *arg) > if (r == EXCP_DEBUG) { > cpu_handle_guest_debug(cpu); > break; > + } else if (r == EXCP_ATOMIC) { > + qemu_mutex_unlock_iothread(); > + cpu_exec_step_atomic(cpu); > + qemu_mutex_lock_iothread(); > + break; > } > } else if (cpu->stop) { > if (cpu->unplug) { > @@ -1457,6 +1462,10 @@ static void *qemu_tcg_cpu_thread_fn(void *arg) > */ > g_assert(cpu->halted); > break; > + case EXCP_ATOMIC: > + qemu_mutex_unlock_iothread(); > + cpu_exec_step_atomic(cpu); > + qemu_mutex_lock_iothread(); > default: > /* Ignore everything else? */ > break; -- Alex Bennée ^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: [Qemu-devel] [PATCH] mttcg: Set jmp_env to handle exit from tb_gen_code 2017-02-21 0:35 ` Alex Bennée @ 2017-02-21 4:05 ` Pranith Kumar 0 siblings, 0 replies; 7+ messages in thread From: Pranith Kumar @ 2017-02-21 4:05 UTC (permalink / raw) To: Alex Bennée; +Cc: qemu-devel, Richard Henderson On Mon, Feb 20, 2017 at 7:35 PM, Alex Bennée <alex.bennee@linaro.org> wrote: > > Pranith Kumar <bobby.prani@gmail.com> writes: > >> Alex Bennée writes: >> >>> Pranith Kumar <bobby.prani@gmail.com> writes: >>> >>>> tb_gen_code() can exit execution using cpu_exit_loop() when it cannot >>>> allocate new tb's. To handle this, we need to properly set the jmp_env >>>> pointer ahead of calling tb_gen_code(). >>>> >>>> CC:Alex Bennée <alex.bennee@linaro.org> >>>> CC: Richard Henderson <rth@twiddle.net> >>>> Signed-off-by: Pranith Kumar <bobby.prani@gmail.com> >>>> --- >>>> cpu-exec.c | 23 +++++++++++------------ >>>> 1 file changed, 11 insertions(+), 12 deletions(-) >>>> >>>> diff --git a/cpu-exec.c b/cpu-exec.c >>>> index 97d79612d9..4b70988b24 100644 >>>> --- a/cpu-exec.c >>>> +++ b/cpu-exec.c >>>> @@ -236,23 +236,22 @@ static void cpu_exec_step(CPUState *cpu) >>>> >>>> cpu_get_tb_cpu_state(env, &pc, &cs_base, &flags); >>>> tb_lock(); >>>> - tb = tb_gen_code(cpu, pc, cs_base, flags, >>>> - 1 | CF_NOCACHE | CF_IGNORE_ICOUNT); >>>> - tb->orig_tb = NULL; >>>> - tb_unlock(); >>>> - >>>> - cc->cpu_exec_enter(cpu); >>>> - >>> >>> It occurs to me we are also diverging in our locking pattern from >>> tb_find which takes mmap_lock first. This is a NOP for system emulation >>> but needed for user-emulation (for which we can do cpu_exec_step but not >>> cpu_exec_nocache). >> >> Right. So we have to take the mmap_lock() before calling >> tb_gen_code(). However, this lock is released in the error path before calling >> cpu_loop_exit() if allocation of a new tb fails. The following is what I have >> after merging with the previous EXCP_ATOMIC handling patch. > > Hmm we are a start/end_exclusive() though so what could we be racing > against that also wants the mmap_lock()? Could it be held by anything at > this point as every user needs to be woken up? > No, I don't think any other thread holds the mmap/tb lock at this point. However, we still need to take this lock since the functions we are calling expect us to hold it and assert otherwise. -- Pranith ^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: [Qemu-devel] [PATCH] mttcg: Set jmp_env to handle exit from tb_gen_code 2017-02-20 23:56 ` Pranith Kumar 2017-02-21 0:35 ` Alex Bennée @ 2017-02-21 15:04 ` Alex Bennée 2017-02-21 16:17 ` Pranith Kumar 1 sibling, 1 reply; 7+ messages in thread From: Alex Bennée @ 2017-02-21 15:04 UTC (permalink / raw) To: Pranith Kumar; +Cc: qemu-devel, rth Pranith Kumar <bobby.prani@gmail.com> writes: > Alex Bennée writes: > >> Pranith Kumar <bobby.prani@gmail.com> writes: >> >>> tb_gen_code() can exit execution using cpu_exit_loop() when it cannot >>> allocate new tb's. To handle this, we need to properly set the jmp_env >>> pointer ahead of calling tb_gen_code(). >>> >>> CC:Alex Bennée <alex.bennee@linaro.org> >>> CC: Richard Henderson <rth@twiddle.net> >>> Signed-off-by: Pranith Kumar <bobby.prani@gmail.com> >>> --- >>> cpu-exec.c | 23 +++++++++++------------ >>> 1 file changed, 11 insertions(+), 12 deletions(-) >>> >>> diff --git a/cpu-exec.c b/cpu-exec.c >>> index 97d79612d9..4b70988b24 100644 >>> --- a/cpu-exec.c >>> +++ b/cpu-exec.c >>> @@ -236,23 +236,22 @@ static void cpu_exec_step(CPUState *cpu) >>> >>> cpu_get_tb_cpu_state(env, &pc, &cs_base, &flags); >>> tb_lock(); >>> - tb = tb_gen_code(cpu, pc, cs_base, flags, >>> - 1 | CF_NOCACHE | CF_IGNORE_ICOUNT); >>> - tb->orig_tb = NULL; >>> - tb_unlock(); >>> - >>> - cc->cpu_exec_enter(cpu); >>> - >> >> It occurs to me we are also diverging in our locking pattern from >> tb_find which takes mmap_lock first. This is a NOP for system emulation >> but needed for user-emulation (for which we can do cpu_exec_step but not >> cpu_exec_nocache). > > Right. So we have to take the mmap_lock() before calling > tb_gen_code(). However, this lock is released in the error path before calling > cpu_loop_exit() if allocation of a new tb fails. The following is what I have > after merging with the previous EXCP_ATOMIC handling patch. > > diff --git a/cpu-exec.c b/cpu-exec.c > index a8e04bffbf..2bb3ba3672 100644 > --- a/cpu-exec.c > +++ b/cpu-exec.c > @@ -228,6 +228,7 @@ static void cpu_exec_nocache(CPUState *cpu, int max_cycles, > > static void cpu_exec_step(CPUState *cpu) > { > + CPUClass *cc = CPU_GET_CLASS(cpu); > CPUArchState *env = (CPUArchState *)cpu->env_ptr; > TranslationBlock *tb; > target_ulong cs_base, pc; > @@ -235,16 +236,24 @@ static void cpu_exec_step(CPUState *cpu) > > cpu_get_tb_cpu_state(env, &pc, &cs_base, &flags); > tb_lock(); > - tb = tb_gen_code(cpu, pc, cs_base, flags, > - 1 | CF_NOCACHE | CF_IGNORE_ICOUNT); > - tb->orig_tb = NULL; > - tb_unlock(); > - /* execute the generated code */ > - trace_exec_tb_nocache(tb, pc); > - cpu_tb_exec(cpu, tb); > - tb_lock(); > - tb_phys_invalidate(tb, -1); > - tb_free(tb); > + if (sigsetjmp(cpu->jmp_env, 0) == 0) { > + mmap_lock(); That gets the locking order the wrong way around - I'm wary of that. > + tb = tb_gen_code(cpu, pc, cs_base, flags, > + 1 | CF_NOCACHE | CF_IGNORE_ICOUNT); > + tb->orig_tb = NULL; > + mmap_unlock(); > + tb_unlock(); > + > + cc->cpu_exec_enter(cpu); > + /* execute the generated code */ > + trace_exec_tb_nocache(tb, pc); > + cpu_tb_exec(cpu, tb); > + cc->cpu_exec_exit(cpu); > + > + tb_lock(); > + tb_phys_invalidate(tb, -1); > + tb_free(tb); > + } > tb_unlock(); > } > > diff --git a/cpus.c b/cpus.c > index 77bba08f9a..b39408b4b1 100644 > --- a/cpus.c > +++ b/cpus.c > @@ -1347,6 +1347,11 @@ static void *qemu_tcg_rr_cpu_thread_fn(void *arg) > if (r == EXCP_DEBUG) { > cpu_handle_guest_debug(cpu); > break; > + } else if (r == EXCP_ATOMIC) { > + qemu_mutex_unlock_iothread(); > + cpu_exec_step_atomic(cpu); > + qemu_mutex_lock_iothread(); > + break; > } > } else if (cpu->stop) { > if (cpu->unplug) { > @@ -1457,6 +1462,10 @@ static void *qemu_tcg_cpu_thread_fn(void *arg) > */ > g_assert(cpu->halted); > break; > + case EXCP_ATOMIC: > + qemu_mutex_unlock_iothread(); > + cpu_exec_step_atomic(cpu); > + qemu_mutex_lock_iothread(); > default: > /* Ignore everything else? */ > break; -- Alex Bennée ^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: [Qemu-devel] [PATCH] mttcg: Set jmp_env to handle exit from tb_gen_code 2017-02-21 15:04 ` Alex Bennée @ 2017-02-21 16:17 ` Pranith Kumar 0 siblings, 0 replies; 7+ messages in thread From: Pranith Kumar @ 2017-02-21 16:17 UTC (permalink / raw) To: Alex Bennée; +Cc: qemu-devel, rth Alex Bennée writes: > Pranith Kumar <bobby.prani@gmail.com> writes: > >> Alex Bennée writes: >> >>> Pranith Kumar <bobby.prani@gmail.com> writes: >>> >>>> tb_gen_code() can exit execution using cpu_exit_loop() when it cannot >>>> allocate new tb's. To handle this, we need to properly set the jmp_env >>>> pointer ahead of calling tb_gen_code(). >>>> >>>> CC:Alex Bennée <alex.bennee@linaro.org> >>>> CC: Richard Henderson <rth@twiddle.net> >>>> Signed-off-by: Pranith Kumar <bobby.prani@gmail.com> >>>> --- >>>> cpu-exec.c | 23 +++++++++++------------ >>>> 1 file changed, 11 insertions(+), 12 deletions(-) >>>> >>>> diff --git a/cpu-exec.c b/cpu-exec.c >>>> index 97d79612d9..4b70988b24 100644 >>>> --- a/cpu-exec.c >>>> +++ b/cpu-exec.c >>>> @@ -236,23 +236,22 @@ static void cpu_exec_step(CPUState *cpu) >>>> >>>> cpu_get_tb_cpu_state(env, &pc, &cs_base, &flags); >>>> tb_lock(); >>>> - tb = tb_gen_code(cpu, pc, cs_base, flags, >>>> - 1 | CF_NOCACHE | CF_IGNORE_ICOUNT); >>>> - tb->orig_tb = NULL; >>>> - tb_unlock(); >>>> - >>>> - cc->cpu_exec_enter(cpu); >>>> - >>> >>> It occurs to me we are also diverging in our locking pattern from >>> tb_find which takes mmap_lock first. This is a NOP for system emulation >>> but needed for user-emulation (for which we can do cpu_exec_step but not >>> cpu_exec_nocache). >> >> Right. So we have to take the mmap_lock() before calling >> tb_gen_code(). However, this lock is released in the error path before calling >> cpu_loop_exit() if allocation of a new tb fails. The following is what I have >> after merging with the previous EXCP_ATOMIC handling patch. >> >> diff --git a/cpu-exec.c b/cpu-exec.c >> index a8e04bffbf..2bb3ba3672 100644 >> --- a/cpu-exec.c >> +++ b/cpu-exec.c >> @@ -228,6 +228,7 @@ static void cpu_exec_nocache(CPUState *cpu, int max_cycles, >> >> static void cpu_exec_step(CPUState *cpu) >> { >> + CPUClass *cc = CPU_GET_CLASS(cpu); >> CPUArchState *env = (CPUArchState *)cpu->env_ptr; >> TranslationBlock *tb; >> target_ulong cs_base, pc; >> @@ -235,16 +236,24 @@ static void cpu_exec_step(CPUState *cpu) >> >> cpu_get_tb_cpu_state(env, &pc, &cs_base, &flags); >> tb_lock(); >> - tb = tb_gen_code(cpu, pc, cs_base, flags, >> - 1 | CF_NOCACHE | CF_IGNORE_ICOUNT); >> - tb->orig_tb = NULL; >> - tb_unlock(); >> - /* execute the generated code */ >> - trace_exec_tb_nocache(tb, pc); >> - cpu_tb_exec(cpu, tb); >> - tb_lock(); >> - tb_phys_invalidate(tb, -1); >> - tb_free(tb); >> + if (sigsetjmp(cpu->jmp_env, 0) == 0) { >> + mmap_lock(); > > That gets the locking order the wrong way around - I'm wary of that. > But we are in exclusive execution now, and we are releasing all the lock taken before coming out of it. I think that should be OK. If your concern is that this is not the normal locking pattern, then I agree. Otherwise, it should be fine. -- Pranith ^ permalink raw reply [flat|nested] 7+ messages in thread
end of thread, other threads:[~2017-02-21 16:18 UTC | newest] Thread overview: 7+ messages (download: mbox.gz follow: Atom feed -- links below jump to the message on this page -- 2017-02-20 14:53 [Qemu-devel] [PATCH] mttcg: Set jmp_env to handle exit from tb_gen_code Pranith Kumar 2017-02-20 16:16 ` Alex Bennée 2017-02-20 23:56 ` Pranith Kumar 2017-02-21 0:35 ` Alex Bennée 2017-02-21 4:05 ` Pranith Kumar 2017-02-21 15:04 ` Alex Bennée 2017-02-21 16:17 ` Pranith Kumar
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for NNTP newsgroup(s).