From mboxrd@z Thu Jan 1 00:00:00 1970 From: Benjamin Herrenschmidt Subject: Re: Reset problem vs. MMIO emulation, hypercalls, etc... Date: Sat, 04 Aug 2012 08:32:10 +1000 Message-ID: <1344033130.24037.69.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> Mime-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 7bit Cc: Avi Kivity , kvm@vger.kernel.org, Alexander Graf , Paul Mackerras , kvm-ppc@vger.kernel.org To: Marcelo Tosatti Return-path: Received: from gate.crashing.org ([63.228.1.57]:42546 "EHLO gate.crashing.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753506Ab2HCWc0 (ORCPT ); Fri, 3 Aug 2012 18:32:26 -0400 In-Reply-To: <20120803180549.GB13174@amt.cnet> Sender: kvm-owner@vger.kernel.org List-ID: 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... Cheers, Ben.