target/i386: fix hang when using slow path for ptw_setl
When instrumenting memory accesses for plugin, we force memory accesses to use the slow path for mmu [1]. This create a situation where we end up calling ptw_setl_slow. This was fixed recently in [2] but the issue still could appear out of plugins use case. Since this function gets called during a cpu_exec, start_exclusive then hangs. This exclusive section was introduced initially for security reasons [3]. I suspect this code path was never triggered, because ptw_setl_slow would always be called transitively from cpu_exec, resulting in a hang. [1]6d03226b42
[2]115ade42d5
[3] https://gitlab.com/qemu-project/qemu/-/issues/279 Fixes: https://gitlab.com/qemu-project/qemu/-/issues/2566 Signed-off-by: Pierrick Bouvier <pierrick.bouvier@linaro.org> Reviewed-by: Richard Henderson <richard.henderson@linaro.org> Message-ID: <20241025175857.2554252-2-pierrick.bouvier@linaro.org> Signed-off-by: Richard Henderson <richard.henderson@linaro.org>
This commit is contained in:
parent
ef7e76a2cd
commit
7ba055b49b
@ -107,6 +107,10 @@ static bool ptw_setl_slow(const PTETranslate *in, uint32_t old, uint32_t new)
|
||||
{
|
||||
uint32_t cmp;
|
||||
|
||||
CPUState *cpu = env_cpu(in->env);
|
||||
/* We are in cpu_exec, and start_exclusive can't be called directly.*/
|
||||
g_assert(cpu->running);
|
||||
cpu_exec_end(cpu);
|
||||
/* Does x86 really perform a rmw cycle on mmio for ptw? */
|
||||
start_exclusive();
|
||||
cmp = cpu_ldl_mmuidx_ra(in->env, in->gaddr, in->ptw_idx, 0);
|
||||
@ -114,6 +118,7 @@ static bool ptw_setl_slow(const PTETranslate *in, uint32_t old, uint32_t new)
|
||||
cpu_stl_mmuidx_ra(in->env, in->gaddr, new, in->ptw_idx, 0);
|
||||
}
|
||||
end_exclusive();
|
||||
cpu_exec_start(cpu);
|
||||
return cmp == old;
|
||||
}
|
||||
|
||||
|
Loading…
Reference in New Issue
Block a user