On 08/02/2012 11:29 PM, Benjamin Herrenschmidt wrote: > On Thu, 2012-08-02 at 16:05 +0300, Avi Kivity wrote: >> > Yeah, we stumbled over this chunk as well. So you're saying we >> should delay the reset by invoking a self-signal if we're in such an >> operation? >> >> Yes. Qemu of course already supports this for migration, so it should >> be easy to add. > > Adding a self signal for the CPU initiating the reset is not enough, > other VCPUs might also be in an hcall or MMIO emulation when that > happens. That happens naturally if you update (or read) registers through a run_on_cpu() call. run_on_cpu() should never happen within an mmio sequence. > > It must be done for all VCPUs, so best is to look at the migration > situation. > > For reset, there are two code path at play: > > - The VCPU initiating the request: It calls qemu_system_reset_request() > which calls cpu_stop_current() directly after signaling the main loop > > - The other VCPUs are then marked with the "stop" flag by the maintloop > which will then wait for them to set "stopped" to 1, which is done by > qemu_wait_io_event_common() when it sees "stop". > > Now, it seems like suspend also uses that same technique. I don't > totally grasp where migration fits in that picture and where it does the > KVM_RUN with a signal pending trick to complete pending operations, any > chance you can enlighten me ? I'm afraid I no longer know the details so closely, the code has changed quite a lot. But the self-signal happens in kvm_cpu_exec(), see also env->exit_request. -- error compiling committee.c: too many arguments to function -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
