On 29/03/21 12:55, Pavel Dovgalyuk wrote:
Is the "or" saying that the execution is using the lockstep mode? If
so, can you put it in a separate function so that it's more
self-explanatory and check if it should be used elsewhere?
It was replay (is that lockstep that you mentioned?).
Loc
On 29.03.2021 12:42, Paolo Bonzini wrote:
On 29/03/21 10:05, Pavel Dovgalyuk wrote:
@@ -136,7 +137,13 @@ void do_run_on_cpu(CPUState *cpu, run_on_cpu_func
func, run_on_cpu_data data,
{
struct qemu_work_item wi;
- if (qemu_cpu_is_self(cpu)) {
+ if (qemu_cpu_is_self(cpu)
+ /*
On 29/03/21 10:05, Pavel Dovgalyuk wrote:
@@ -136,7 +137,13 @@ void do_run_on_cpu(CPUState *cpu, run_on_cpu_func func,
run_on_cpu_data data,
{
struct qemu_work_item wi;
-if (qemu_cpu_is_self(cpu)) {
+if (qemu_cpu_is_self(cpu)
+/*
+ * vCPU thread is waiting whe
In record/replay mode waiting for vCPU to execute
the task scheduled by run_on_cpu may lead to deadlock,
because when run_on_cpu is executed in main_loop
(e.g., in loadvm processing) it holds replay mutex.
This patch allows running scheduled task in iothread
when it holds the replay mutex.
Signed-
ping
On 11.03.2021 10:14, Pavel Dovgalyuk wrote:
In record/replay mode waiting for vCPU to execute
the task scheduled by run_on_cpu may lead to deadlock,
because when run_on_cpu is executed in main_loop
(e.g., in loadvm processing) it holds replay mutex.
This patch allows running scheduled task
In record/replay mode waiting for vCPU to execute
the task scheduled by run_on_cpu may lead to deadlock,
because when run_on_cpu is executed in main_loop
(e.g., in loadvm processing) it holds replay mutex.
This patch allows running scheduled task in iothread
when it holds the replay mutex.
Signed-
