On 08/04/2012 01:32 AM, Benjamin Herrenschmidt wrote: > On Fri, 2012-08-03 at 15:05 -0300, Marcelo Tosatti wrote: > >> See kvm_arch_process_async_events() call to qemu_system_reset_request() >> in target-i386/kvm.c. >> >> The whole thing is fragile, though: we rely on the order events >> are processed inside KVM_RUN, in x86: >> >> 1) If there is pending MMIO, process it. >> 2) If not, return with -EINTR (and KVM_EXIT_INTR) in case >> there is a signal pending. >> >> That way, the vcpu will not process the stop event from the main loop >> (ie not exit from the kvm_cpu_exec() loop), until MMIO is finished. > > Right, it is fragile, thankfully we appear to adhere to the same > ordering on powerpc so far :-) > > So we'll need to test but it looks like we might be able to fix our > problem without a kernel or API change, just by changing qemu to > do the same exit_request trick for our reboot hypercall. > > Long run however, I wonder whether we should consider an explicit ioctl > to complete those pending operations instead... It's pointless. We have to support the old method forever. There's no material different between sigqueue() + KVM_RUN and KVM_COMPLETE, or a KVM_RUN with a flag that tells it to exit immediately. -- 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
