From mboxrd@z Thu Jan 1 00:00:00 1970 From: Alexander Graf Subject: Re: [PATCH] KVM: PPC: BOOK3S: PR: Fix WARN_ON with debug options on Date: Wed, 07 May 2014 13:37:53 +0200 Message-ID: <536A1B11.2030101@suse.de> References: <1399224368-22122-1-git-send-email-aneesh.kumar@linux.vnet.ibm.com> <20140507055626.GA26650@iris.ozlabs.ibm.com> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "Aneesh Kumar K.V" , benh@kernel.crashing.org, linuxppc-dev@lists.ozlabs.org, kvm-ppc@vger.kernel.org, kvm@vger.kernel.org To: Paul Mackerras Return-path: Received: from cantor2.suse.de ([195.135.220.15]:59098 "EHLO mx2.suse.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S932243AbaEGLhz (ORCPT ); Wed, 7 May 2014 07:37:55 -0400 In-Reply-To: <20140507055626.GA26650@iris.ozlabs.ibm.com> Sender: kvm-owner@vger.kernel.org List-ID: On 05/07/2014 07:56 AM, Paul Mackerras wrote: > On Sun, May 04, 2014 at 10:56:08PM +0530, Aneesh Kumar K.V wrote: >> With debug option "sleep inside atomic section checking" enabled we get >> the below WARN_ON during a PR KVM boot. This is because upstream now >> have PREEMPT_COUNT enabled even if we have preempt disabled. Fix the >> warning by adding preempt_disable/enable around floating point and altivec >> enable. > This worries me a bit. In this code: > >> if (msr & MSR_FP) { >> + preempt_disable(); >> enable_kernel_fp(); >> load_fp_state(&vcpu->arch.fp); >> t->fp_save_area = &vcpu->arch.fp; >> + preempt_enable(); > What would happen if we actually did get preempted at this point? > Wouldn't we lose the FP state we just loaded? > > In other words, how come we're not already preempt-disabled at this > point? This is probably because we're trying to confuse Linux :). The entry path happens with interrupts hard disabled, but preempt enabled so that Linux doesn't consider the guest time as non-preemptible. That's the only call I could find where preempt is logically enabled (though it really isn't). Alex