From mboxrd@z Thu Jan 1 00:00:00 1970 From: Scott Wood Date: Wed, 05 Jun 2013 19:07:34 +0000 Subject: Re: [RFC PATCH 2/6] KVM: PPC: Book3E: Refactor SPE_FP exit handling Message-Id: <1370459254.26139.7@snotra> List-Id: References: <300B73AA675FCE4A93EB4FC1D42459FF44EBF7@039-SN2MPN1-011.039d.mgd.msft.net> In-Reply-To: <300B73AA675FCE4A93EB4FC1D42459FF44EBF7@039-SN2MPN1-011.039d.mgd.msft.net> (from B02008@freescale.com on Wed Jun 5 02:29:47 2013) MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: Caraman Mihai Claudiu-B02008 Cc: Wood Scott-B07421 , "kvm-ppc@vger.kernel.org" , "kvm@vger.kernel.org" , "linuxppc-dev@lists.ozlabs.org" On 06/05/2013 02:29:47 AM, Caraman Mihai Claudiu-B02008 wrote: > > > case BOOKE_INTERRUPT_SPE_FP_ROUND: > > > +#ifdef CONFIG_SPE > > > kvmppc_booke_queue_irqprio(vcpu, > > > BOOKE_IRQPRIO_SPE_FP_ROUND); > > > r = RESUME_GUEST; > > > break; > > > > Why not use kvmppc_supports_spe() here, for consistency? > > I added cpu_has_feature(CPU_FTR_SPE) for the case specified above, > but here > SPE_FP_ROUND is not shared with ALTIVEC. CONFIG_SPE is used in other > places > in KVM without this check, shouldn't be all or nothing? I'd rather it be consistent, at least between handling one exception and another. -Scott From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from co1outboundpool.messaging.microsoft.com (co1ehsobe003.messaging.microsoft.com [216.32.180.186]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (Client CN "mail.global.frontbridge.com", Issuer "MSIT Machine Auth CA 2" (not verified)) by ozlabs.org (Postfix) with ESMTPS id 4520E2C02A7 for ; Thu, 6 Jun 2013 05:07:45 +1000 (EST) Date: Wed, 5 Jun 2013 14:07:34 -0500 From: Scott Wood Subject: Re: [RFC PATCH 2/6] KVM: PPC: Book3E: Refactor SPE_FP exit handling To: Caraman Mihai Claudiu-B02008 In-Reply-To: <300B73AA675FCE4A93EB4FC1D42459FF44EBF7@039-SN2MPN1-011.039d.mgd.msft.net> (from B02008@freescale.com on Wed Jun 5 02:29:47 2013) Message-ID: <1370459254.26139.7@snotra> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; delsp=Yes; format=Flowed Cc: Wood Scott-B07421 , "linuxppc-dev@lists.ozlabs.org" , "kvm@vger.kernel.org" , "kvm-ppc@vger.kernel.org" List-Id: Linux on PowerPC Developers Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , On 06/05/2013 02:29:47 AM, Caraman Mihai Claudiu-B02008 wrote: > > > case BOOKE_INTERRUPT_SPE_FP_ROUND: > > > +#ifdef CONFIG_SPE > > > kvmppc_booke_queue_irqprio(vcpu, > > > BOOKE_IRQPRIO_SPE_FP_ROUND); > > > r =3D RESUME_GUEST; > > > break; > > > > Why not use kvmppc_supports_spe() here, for consistency? >=20 > I added cpu_has_feature(CPU_FTR_SPE) for the case specified above, =20 > but here > SPE_FP_ROUND is not shared with ALTIVEC. CONFIG_SPE is used in other =20 > places > in KVM without this check, shouldn't be all or nothing? I'd rather it be consistent, at least between handling one exception =20 and another. -Scott= From mboxrd@z Thu Jan 1 00:00:00 1970 From: Scott Wood Subject: Re: [RFC PATCH 2/6] KVM: PPC: Book3E: Refactor SPE_FP exit handling Date: Wed, 5 Jun 2013 14:07:34 -0500 Message-ID: <1370459254.26139.7@snotra> References: <300B73AA675FCE4A93EB4FC1D42459FF44EBF7@039-SN2MPN1-011.039d.mgd.msft.net> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; delsp=Yes; format=Flowed Content-Transfer-Encoding: 8BIT Cc: Wood Scott-B07421 , "kvm-ppc@vger.kernel.org" , "kvm@vger.kernel.org" , "linuxppc-dev@lists.ozlabs.org" To: Caraman Mihai Claudiu-B02008 Return-path: In-Reply-To: <300B73AA675FCE4A93EB4FC1D42459FF44EBF7@039-SN2MPN1-011.039d.mgd.msft.net> (from B02008@freescale.com on Wed Jun 5 02:29:47 2013) Content-Disposition: inline Sender: kvm-ppc-owner@vger.kernel.org List-Id: kvm.vger.kernel.org On 06/05/2013 02:29:47 AM, Caraman Mihai Claudiu-B02008 wrote: > > > case BOOKE_INTERRUPT_SPE_FP_ROUND: > > > +#ifdef CONFIG_SPE > > > kvmppc_booke_queue_irqprio(vcpu, > > > BOOKE_IRQPRIO_SPE_FP_ROUND); > > > r = RESUME_GUEST; > > > break; > > > > Why not use kvmppc_supports_spe() here, for consistency? > > I added cpu_has_feature(CPU_FTR_SPE) for the case specified above, > but here > SPE_FP_ROUND is not shared with ALTIVEC. CONFIG_SPE is used in other > places > in KVM without this check, shouldn't be all or nothing? I'd rather it be consistent, at least between handling one exception and another. -Scott