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. 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 ? Thanks ! Cheers, Ben. -- 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
