From mboxrd@z Thu Jan 1 00:00:00 1970 From: Benjamin Herrenschmidt Subject: Re: Reset problem vs. MMIO emulation, hypercalls, etc... Date: Fri, 03 Aug 2012 06:20:18 +1000 Message-ID: <1343938818.6911.9.camel@pasglop> References: <1343791031.16975.41.camel@pasglop> <501A740F.2000000@redhat.com> Mime-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 7bit Cc: kvm@vger.kernel.org, Alexander Graf , Paul Mackerras , kvm-ppc@vger.kernel.org To: Avi Kivity Return-path: In-Reply-To: <501A740F.2000000@redhat.com> Sender: kvm-ppc-owner@vger.kernel.org List-Id: kvm.vger.kernel.org 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.