From mboxrd@z Thu Jan 1 00:00:00 1970 From: Benjamin Herrenschmidt Subject: Re: Reset problem vs. MMIO emulation, hypercalls, etc... Date: Mon, 06 Aug 2012 06:45:23 +1000 Message-ID: <1344199523.24037.90.camel@pasglop> References: <1343791031.16975.41.camel@pasglop> <501A740F.2000000@redhat.com> <501A7B31.9060506@redhat.com> <1343939348.6911.15.camel@pasglop> <501E351C.8080603@redhat.com> Mime-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 7bit Cc: Alexander Graf , kvm@vger.kernel.org, Paul Mackerras , kvm-ppc@vger.kernel.org To: Avi Kivity Return-path: In-Reply-To: <501E351C.8080603@redhat.com> Sender: kvm-ppc-owner@vger.kernel.org List-Id: kvm.vger.kernel.org On Sun, 2012-08-05 at 11:55 +0300, Avi Kivity wrote: > > I'm afraid I no longer know the details so closely, the code has > changed > quite a lot. But the self-signal happens in kvm_cpu_exec(), see also > env->exit_request. Right, I think I eventually grasped it :-) It is fairly fragile however, it basically relies that none of those things that leave the kernel in an "incomplete" state (hcalls, mmio emulation, ...) return a non-zero value, but instead only ever request an exit via exit_request, so that we are guaranteed that the exec loop -will- go back, send that signal and finally exit as a result of EINTR. It also requires that the kernel tests & handles all those "completion" early in VCPU_RUN before it does anything else really including testing for signals. The latter seems fine for us, the former was what we got wrong on ppc: our hypercalls always cause exits via a non-zero return value for some reason (I didn't write that code, not sure exactly why it was written like that). Working on fixing that on qemu side now. Thanks ! Cheers, Ben.