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. Paolo
