| Message ID | 20161102142559.23395-1-bobby.prani@gmail.com (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
Pranith Kumar <bobby.prani@gmail.com> writes: > The patch enables handling atomic code in the guest. This should be > preferably done in cpu_handle_exception(), but the current assumptions > regarding when we can execute atomic sections cause a deadlock. > > Signed-off-by: Pranith Kumar <bobby.prani@gmail.com> > --- > cpus.c | 7 +++++++ > 1 file changed, 7 insertions(+) > > diff --git a/cpus.c b/cpus.c > index 8f98060..c4ba7d8 100644 > --- a/cpus.c > +++ b/cpus.c > @@ -1315,6 +1315,9 @@ 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) { > + cpu_exec_step_atomic(cpu); > + break; Hmm don't we need to unlock the iothread here as well? I suspect you never see a deadlock because the rr thread can't by definition race with itself but the locking practice should be the same for both cases. > } > } else if (cpu->stop) { > if (cpu->unplug) { > @@ -1385,6 +1388,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
Alex Bennée writes: > Pranith Kumar <bobby.prani@gmail.com> writes: > >> The patch enables handling atomic code in the guest. This should be >> preferably done in cpu_handle_exception(), but the current assumptions >> regarding when we can execute atomic sections cause a deadlock. >> >> Signed-off-by: Pranith Kumar <bobby.prani@gmail.com> >> --- >> cpus.c | 7 +++++++ >> 1 file changed, 7 insertions(+) >> >> diff --git a/cpus.c b/cpus.c >> index 8f98060..c4ba7d8 100644 >> --- a/cpus.c >> +++ b/cpus.c >> @@ -1315,6 +1315,9 @@ 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) { >> + cpu_exec_step_atomic(cpu); >> + break; > > Hmm don't we need to unlock the iothread here as well? I suspect you > never see a deadlock because the rr thread can't by definition race with > itself but the locking practice should be the same for both cases. > Yes, not having any other thread to race with is the reason I did not unlock the iothread. But, I agree that the semantics need to be the same. I will send an updated patch. Thanks,
diff --git a/cpus.c b/cpus.c index 8f98060..c4ba7d8 100644 --- a/cpus.c +++ b/cpus.c @@ -1315,6 +1315,9 @@ 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) { + cpu_exec_step_atomic(cpu); + break; } } else if (cpu->stop) { if (cpu->unplug) { @@ -1385,6 +1388,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;
The patch enables handling atomic code in the guest. This should be preferably done in cpu_handle_exception(), but the current assumptions regarding when we can execute atomic sections cause a deadlock. Signed-off-by: Pranith Kumar <bobby.prani@gmail.com> --- cpus.c | 7 +++++++ 1 file changed, 7 insertions(+)