From mboxrd@z Thu Jan 1 00:00:00 1970 From: Scott Wood Subject: Re: Reset problem vs. MMIO emulation, hypercalls, etc... Date: Mon, 6 Aug 2012 15:25:41 -0500 Message-ID: <50202845.2050605@freescale.com> 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: Benjamin Herrenschmidt , Marcelo Tosatti , , Alexander Graf , Paul Mackerras , 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 08/05/2012 04:00 AM, Avi Kivity wrote: > 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. Not in new architectures (even PPC has yet to start using this) or new userspaces -- and forever is a long time. People down the road may very well decide that it's time to clean out the deprecated stuff that hasn't been used in over a decade. IMHO this shouldn't be a reason to not improve the API, as long as compatibility is possible for as long as it is deemed worthwhile. > 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. The latter is less fragile and easier to use. -Scott