Emilio G. Cota <c...@braap.org> writes:
> Cc: Peter Maydell <peter.mayd...@linaro.org>
> Cc: qemu-...@nongnu.org
> Reviewed-by: Richard Henderson <richard.hender...@linaro.org>
> Signed-off-by: Emilio G. Cota <c...@braap.org>
<snip>
>
> - /* Hooks may change global state so BQL should be held, also the
> - * BQL needs to be held for any modification of
> - * cs->interrupt_request.
> - */
> + /* Hooks may change global state so BQL should be held */
> g_assert(qemu_mutex_iothread_locked());
>
> arm_call_pre_el_change_hook(cpu);
So I dug into this and currently the only user is pmu_pre_el_change
which updates a bunch of the performance counters. While profiling the
system running the other thing that showed up was:
void HELPER(set_cp_reg)(CPUARMState *env, void *rip, uint32_t value)
{
const ARMCPRegInfo *ri = rip;
if (ri->type & ARM_CP_IO) {
qemu_mutex_lock_iothread();
ri->writefn(env, ri, value);
qemu_mutex_unlock_iothread();
} else {
ri->writefn(env, ri, value);
}
}
And friends. I'm wondering now if these are candidates for using CPU
locks. We mention it in out docs (which might be a little out of date now):
MMIO access automatically serialises hardware emulation by way of the
BQL. Currently ARM targets serialise all ARM_CP_IO register accesses
and also defer the reset/startup of vCPUs to the vCPU context by way
of async_run_on_cpu().
for registers that affect things like the GIC that can have cross-vCPU
effects I suspect the race free IRQ raising might be enough. Are we over
locking if only a vCPU can read/write it's own CP regs?
Peter any thoughts?
Anyway as far as this patch goes:
Reviewed-by: Alex Bennée <alex.ben...@linaro.org>
--
Alex Bennée
