On Mon, Oct 29, 2018 at 16:34:49 +0000, Alex Bennée wrote:
>
> Emilio G. Cota <c...@braap.org> writes:
>
> > We don't pass a pointer to qemu_global_mutex anymore.
> >
> > Reviewed-by: Richard Henderson <richard.hender...@linaro.org>
> > Signed-off-by: Emilio G. Cota <c...@braap.org>
>
> As discussed on IRC I don't fundamentally object to this being in
> cpus-common given we have the other work queue stuff there. However
> given it now lives there we should assert we are in system emulation
> mode so if a user-mode instruction attempts to use one of the
> _run_on_cpu() functions we break.
Thanks for looking into this. I fixed up the commit to add stubs for
cpu_lock/unlock, since the former cpu->work_mutex has to keep working.
I'm not convinced about adding an "assert(!user-mode)" to run_on_cpu.
Given that now it does not depend on the BQL, it could actually
work in user-mode if called. If we really wanted to make sure
that no user-mode would call it, then a compile-time check
would be better than an assert. But again, I fail to see what
we'd gain from that.
For context, do_run_on_cpu et al. were moved to cpus-common.c by
d148d90ee8 ("cpus-common: move CPU work item management to
common code", 2016-09-27). The point was to consolidate the
run-on-cpu code in a common (softmmu & user-mode) file, since
user-mode needed async_run_on_cpu for exclusive work.
Now we can finally make run_on_cpu generic as well.
Thanks,
Emilio
