From mboxrd@z Thu Jan 1 00:00:00 1970 From: Scott Wood Subject: Re: [PATCH 3/6] KVM: PPC: booke: Check for MSR[WE] in prepare_to_enter Date: Mon, 14 Nov 2011 12:56:41 -0600 Message-ID: <4EC16469.6090108@freescale.com> References: <20111109002325.GC6132@schlenkerla.am.freescale.net> <4EC1140F.3000307@suse.de> <4EC14E5B.5080805@freescale.com> <1D7AA65D-00B5-4E06-97AD-3912A3D63E9A@suse.de> Mime-Version: 1.0 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 7bit Cc: "" , "" To: Alexander Graf Return-path: In-Reply-To: <1D7AA65D-00B5-4E06-97AD-3912A3D63E9A@suse.de> Sender: kvm-ppc-owner@vger.kernel.org List-Id: kvm.vger.kernel.org On 11/14/2011 12:01 PM, Alexander Graf wrote: > > On 14.11.2011, at 18:22, Scott Wood wrote: > >> kvmppc_core_check_exceptions can clear MSR_WE, so we need to check after >> that. We can't enable interrupts after kvmppc_core_check_exceptions (or >> rather, if we do, we need to check again once interrupts are >> re-disabled, as in the MSR_WE case) because otherwise we could have an >> exception delivered afterward and receive the resched IPI at just the >> wrong time to take any action on it (just like the signal check). > > Well, but if you enable interrupts here you're basically rendering code that runs earlier in disabled-interrupt mode racy. That's why once we wake, we disable interrupts and check again. > How does this align with the signal handling? We could receive a signal here and not handle it the same as the race you fixed earlier, no? Signals are checked by the caller after calling prepare_to_enter. Moving the check into prepare_to_enter wouldn't buy us much since the method of returning is different, and so there'd still need to be code in the caller to deal with it. -Scott