Paolo Bonzini <pbonz...@redhat.com> writes:
> On 01/07/20 22:35, Peter Maydell wrote: >> For the monitor, that >> would be the current "default cpu" as set by the "cpu" >> command (cf monitor_set_cpu()). The bug here will be that >> somewhere along the line we are probably missing plumbing >> sufficient to pass down "which CPU do we want". > > Yeah, the fix is probably to add a functions that returns either > current_cpu or the monitor CPU, and use it in device emulation if > applicable. > > The problem with current_cpu is that it affects stuff like run_on_cpu, > and that is guaranteed to cause havoc to code that expects to run on a > given CPU and therefore doesn't use locks. IIRC the original reported bug was in a APM callback which was triggered by an MMIO operation. Currently we don't expose the current cpu via the memory dispatch routines. Should we to ensure there is always something valid there? > > Paolo -- Alex Bennée
