Message ID | 1463404380-29302-1-git-send-email-sergey.fedorov@linaro.org |
---|---|
State | New |
Headers | show |
On 05/16/2016 06:13 AM, Sergey Fedorov wrote: > It is not safe to make a direct jump to a TB spanning two pages in > system emulation because the mapping for the second page can get changed > but we don't take care of direct jumps in this case. We don't? I'm pretty sure that we do... r~
On 16/05/16 16:49, Richard Henderson wrote: > On 05/16/2016 06:13 AM, Sergey Fedorov wrote: >> It is not safe to make a direct jump to a TB spanning two pages in >> system emulation because the mapping for the second page can get changed >> but we don't take care of direct jumps in this case. > We don't? I'm pretty sure that we do... What we just do is flushing the CPU virtual address cache, see for tlb_flush() etc. Kind regards, Sergey
On Mon, May 16, 2016 at 04:13:00PM +0300, Sergey Fedorov wrote: > From: Sergey Fedorov <serge.fdrv@gmail.com> > > It is not safe to make a direct jump to a TB spanning two pages in > system emulation because the mapping for the second page can get changed > but we don't take care of direct jumps in this case. > > However in user mode emulation, this is not the case because there's > only static address translation and TBs are always invalidated properly. > > Fixes: 5b053a4a2827 ("tcg: Clean up direct block chaining safety checks") > > Reported-by: Max Filippov <jcmvbkbc@gmail.com> > Signed-off-by: Sergey Fedorov <serge.fdrv@gmail.com> > Signed-off-by: Sergey Fedorov <sergey.fedorov@linaro.org> > --- > cpu-exec.c | 9 +++++++++ > 1 file changed, 9 insertions(+) Tested-by: Max Filippov <jcmvbkbc@gmail.com>
On 16/05/16 17:36, Sergey Fedorov wrote: > On 16/05/16 16:49, Richard Henderson wrote: >> On 05/16/2016 06:13 AM, Sergey Fedorov wrote: >>> It is not safe to make a direct jump to a TB spanning two pages in >>> system emulation because the mapping for the second page can get changed >>> but we don't take care of direct jumps in this case. >> We don't? I'm pretty sure that we do... > What we just do is flushing the CPU virtual address cache, see for > tlb_flush() etc. Ping. This patch fixed a bug discussed in this thread: http://thread.gmane.org/gmane.comp.emulators.qemu/411648 Kind regards, Sergey
On 25 May 2016 at 17:37, Sergey Fedorov <serge.fdrv@gmail.com> wrote: > On 16/05/16 17:36, Sergey Fedorov wrote: >> On 16/05/16 16:49, Richard Henderson wrote: >>> On 05/16/2016 06:13 AM, Sergey Fedorov wrote: >>>> It is not safe to make a direct jump to a TB spanning two pages in >>>> system emulation because the mapping for the second page can get changed >>>> but we don't take care of direct jumps in this case. >>> We don't? I'm pretty sure that we do... >> What we just do is flushing the CPU virtual address cache, see for >> tlb_flush() etc. > > Ping. This patch fixed a bug discussed in this thread: > http://thread.gmane.org/gmane.comp.emulators.qemu/411648 Applied to master, thanks. -- PMM
diff --git a/cpu-exec.c b/cpu-exec.c index 14df1aacf42a..ec2364df624d 100644 --- a/cpu-exec.c +++ b/cpu-exec.c @@ -344,6 +344,15 @@ static inline TranslationBlock *tb_find_fast(CPUState *cpu, *last_tb = NULL; cpu->tb_flushed = false; } +#ifndef CONFIG_USER_ONLY + /* We don't take care of direct jumps when address mapping changes in + * system emulation. So it's not safe to make a direct jump to a TB + * spanning two pages because the mapping for the second page can change. + */ + if (tb->page_addr[1] != -1) { + *last_tb = NULL; + } +#endif /* See if we can patch the calling TB. */ if (*last_tb && !qemu_loglevel_mask(CPU_LOG_TB_NOCHAIN)) { tb_add_jump(*last_tb, tb_exit, tb);