From mboxrd@z Thu Jan 1 00:00:00 1970 From: Benjamin Herrenschmidt Subject: Re: Reset problem vs. MMIO emulation, hypercalls, etc... Date: Tue, 07 Aug 2012 06:54:57 +1000 Message-ID: <1344286497.24037.97.camel@pasglop> References: <1343791031.16975.41.camel@pasglop> <501A740F.2000000@redhat.com> <1343938818.6911.9.camel@pasglop> <20120803174113.GA13174@amt.cnet> <20120803180549.GB13174@amt.cnet> <1344033130.24037.69.camel@pasglop> <501E361A.3030105@redhat.com> Mime-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 7bit Cc: Marcelo Tosatti , kvm@vger.kernel.org, Alexander Graf , Paul Mackerras , kvm-ppc@vger.kernel.org To: Avi Kivity Return-path: In-Reply-To: <501E361A.3030105@redhat.com> Sender: kvm-ppc-owner@vger.kernel.org List-Id: kvm.vger.kernel.org On Sun, 2012-08-05 at 12:00 +0300, Avi Kivity wrote: > > 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. Sort-of... in fact, I would say after more thoughts that the real reason to leave things as-is is that we actually need a clean restartable state for migration, and an ioctl for "aborting" transactions wouldn't complete them properly, which is fine for reset but not for migration or snapshots. Cheers, Ben.