On Thu, 2012-08-02 at 15:35 +0300, Avi Kivity wrote: > This is actually documented in api.txt, though not in relation to > reset: > > NOTE: For KVM_EXIT_IO, KVM_EXIT_MMIO and KVM_EXIT_OSI, the > corresponding operations are complete (and guest state is > consistent) > only after userspace has re-entered the kernel with KVM_RUN. The > kernel side will first finish incomplete operations and then check > for pending signals. Userspace can re-enter the guest with an > unmasked signal pending to complete pending operations. > > For x86 the issue was with live migration - you can't copy guest > register state in the middle of an I/O operation. Reset is actually > similar, but it involves writing state (which can then be overwritten) > instead of reading it. Hrm, except that doing KVM_RUN with a signal is very cumbersome to do and I couldn't quite find the logic in qemu to do it ... but I might just have missed it. I can see indeed that in the migration case you want to actually complete the operation rather than just "abort it". Any chance you can point me to the code that performs that trick qemu side for migration ? Anthony seems to think that for reset we can just abort the operation state in the kernel when the MP state changes. 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
