From: Scott Wood <scottwood@freescale.com>
To: Mihai Caraman <mihai.caraman@freescale.com>
Cc: kvm-ppc@vger.kernel.org, kvm@vger.kernel.org,
linuxppc-dev@lists.ozlabs.org,
Mihai Caraman <mihai.caraman@freescale.com>
Subject: Re: [RFC PATCH 2/6] KVM: PPC: Book3E: Refactor SPE_FP exit handling
Date: Tue, 04 Jun 2013 22:14:48 +0000 [thread overview]
Message-ID: <1370384088.748.17@snotra> (raw)
In-Reply-To: <1370292868-2697-3-git-send-email-mihai.caraman@freescale.com> (from mihai.caraman@freescale.com on Mon Jun 3 15:54:24 2013)
On 06/03/2013 03:54:24 PM, Mihai Caraman wrote:
> SPE_FP interrupts are shared with ALTIVEC. Refactor SPE_FP exit
> handling
> to detect KVM support for the featured unit at run-time, in order to
> accommodate ALTIVEC later.
>
> Signed-off-by: Mihai Caraman <mihai.caraman@freescale.com>
> ---
> arch/powerpc/kvm/booke.c | 80
> ++++++++++++++++++++++++++++++++++------------
> 1 files changed, 59 insertions(+), 21 deletions(-)
>
> diff --git a/arch/powerpc/kvm/booke.c b/arch/powerpc/kvm/booke.c
> index 1020119..d082bbc 100644
> --- a/arch/powerpc/kvm/booke.c
> +++ b/arch/powerpc/kvm/booke.c
> @@ -822,6 +822,15 @@ static void kvmppc_restart_interrupt(struct
> kvm_vcpu *vcpu,
> }
> }
>
> +static inline bool kvmppc_supports_spe(void)
> +{
> +#ifdef CONFIG_SPE
> + if (cpu_has_feature(CPU_FTR_SPE))
> + return true;
> +#endif
> + return false;
> +}
Whitespace
> /**
> * kvmppc_handle_exit
> *
> @@ -931,42 +940,71 @@ int kvmppc_handle_exit(struct kvm_run *run,
> struct kvm_vcpu *vcpu,
> r = RESUME_GUEST;
> break;
>
> -#ifdef CONFIG_SPE
> case BOOKE_INTERRUPT_SPE_UNAVAIL: {
> - if (vcpu->arch.shared->msr & MSR_SPE)
> - kvmppc_vcpu_enable_spe(vcpu);
> - else
> - kvmppc_booke_queue_irqprio(vcpu,
> -
> BOOKE_IRQPRIO_SPE_UNAVAIL);
> + /*
> + * The interrupt is shared, KVM support for the
> featured unit
> + * is detected at run-time.
> + */
This is a decent comment for the changelog, but for the code itself it
seems fairly obvious if you look at the definition of
kvmppc_supports_spe().
> + bool handled = false;
> +
> + if (kvmppc_supports_spe()) {
> +#ifdef CONFIG_SPE
> + if (cpu_has_feature(CPU_FTR_SPE))
Didn't you already check this using kvmppc_supports_spe()?
> 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?
-Scott
WARNING: multiple messages have this Message-ID (diff)
From: Scott Wood <scottwood@freescale.com>
To: Mihai Caraman <mihai.caraman@freescale.com>
Cc: Mihai Caraman <mihai.caraman@freescale.com>,
linuxppc-dev@lists.ozlabs.org, kvm@vger.kernel.org,
kvm-ppc@vger.kernel.org
Subject: Re: [RFC PATCH 2/6] KVM: PPC: Book3E: Refactor SPE_FP exit handling
Date: Tue, 4 Jun 2013 17:14:48 -0500 [thread overview]
Message-ID: <1370384088.748.17@snotra> (raw)
In-Reply-To: <1370292868-2697-3-git-send-email-mihai.caraman@freescale.com> (from mihai.caraman@freescale.com on Mon Jun 3 15:54:24 2013)
On 06/03/2013 03:54:24 PM, Mihai Caraman wrote:
> SPE_FP interrupts are shared with ALTIVEC. Refactor SPE_FP exit =20
> handling
> to detect KVM support for the featured unit at run-time, in order to
> accommodate ALTIVEC later.
>=20
> Signed-off-by: Mihai Caraman <mihai.caraman@freescale.com>
> ---
> arch/powerpc/kvm/booke.c | 80 =20
> ++++++++++++++++++++++++++++++++++------------
> 1 files changed, 59 insertions(+), 21 deletions(-)
>=20
> diff --git a/arch/powerpc/kvm/booke.c b/arch/powerpc/kvm/booke.c
> index 1020119..d082bbc 100644
> --- a/arch/powerpc/kvm/booke.c
> +++ b/arch/powerpc/kvm/booke.c
> @@ -822,6 +822,15 @@ static void kvmppc_restart_interrupt(struct =20
> kvm_vcpu *vcpu,
> }
> }
>=20
> +static inline bool kvmppc_supports_spe(void)
> +{
> +#ifdef CONFIG_SPE
> + if (cpu_has_feature(CPU_FTR_SPE))
> + return true;
> +#endif
> + return false;
> +}
Whitespace
> /**
> * kvmppc_handle_exit
> *
> @@ -931,42 +940,71 @@ int kvmppc_handle_exit(struct kvm_run *run, =20
> struct kvm_vcpu *vcpu,
> r =3D RESUME_GUEST;
> break;
>=20
> -#ifdef CONFIG_SPE
> case BOOKE_INTERRUPT_SPE_UNAVAIL: {
> - if (vcpu->arch.shared->msr & MSR_SPE)
> - kvmppc_vcpu_enable_spe(vcpu);
> - else
> - kvmppc_booke_queue_irqprio(vcpu,
> - =20
> BOOKE_IRQPRIO_SPE_UNAVAIL);
> + /*
> + * The interrupt is shared, KVM support for the =20
> featured unit
> + * is detected at run-time.
> + */
This is a decent comment for the changelog, but for the code itself it =20
seems fairly obvious if you look at the definition of =20
kvmppc_supports_spe().
> + bool handled =3D false;
> +
> + if (kvmppc_supports_spe()) {
> +#ifdef CONFIG_SPE
> + if (cpu_has_feature(CPU_FTR_SPE))
Didn't you already check this using kvmppc_supports_spe()?
> case BOOKE_INTERRUPT_SPE_FP_ROUND:
> +#ifdef CONFIG_SPE
> kvmppc_booke_queue_irqprio(vcpu, =20
> BOOKE_IRQPRIO_SPE_FP_ROUND);
> r =3D RESUME_GUEST;
> break;
Why not use kvmppc_supports_spe() here, for consistency?
-Scott=
WARNING: multiple messages have this Message-ID (diff)
From: Scott Wood <scottwood@freescale.com>
To: Mihai Caraman <mihai.caraman@freescale.com>
Cc: <kvm-ppc@vger.kernel.org>, <kvm@vger.kernel.org>,
<linuxppc-dev@lists.ozlabs.org>,
Mihai Caraman <mihai.caraman@freescale.com>
Subject: Re: [RFC PATCH 2/6] KVM: PPC: Book3E: Refactor SPE_FP exit handling
Date: Tue, 4 Jun 2013 17:14:48 -0500 [thread overview]
Message-ID: <1370384088.748.17@snotra> (raw)
In-Reply-To: <1370292868-2697-3-git-send-email-mihai.caraman@freescale.com> (from mihai.caraman@freescale.com on Mon Jun 3 15:54:24 2013)
On 06/03/2013 03:54:24 PM, Mihai Caraman wrote:
> SPE_FP interrupts are shared with ALTIVEC. Refactor SPE_FP exit
> handling
> to detect KVM support for the featured unit at run-time, in order to
> accommodate ALTIVEC later.
>
> Signed-off-by: Mihai Caraman <mihai.caraman@freescale.com>
> ---
> arch/powerpc/kvm/booke.c | 80
> ++++++++++++++++++++++++++++++++++------------
> 1 files changed, 59 insertions(+), 21 deletions(-)
>
> diff --git a/arch/powerpc/kvm/booke.c b/arch/powerpc/kvm/booke.c
> index 1020119..d082bbc 100644
> --- a/arch/powerpc/kvm/booke.c
> +++ b/arch/powerpc/kvm/booke.c
> @@ -822,6 +822,15 @@ static void kvmppc_restart_interrupt(struct
> kvm_vcpu *vcpu,
> }
> }
>
> +static inline bool kvmppc_supports_spe(void)
> +{
> +#ifdef CONFIG_SPE
> + if (cpu_has_feature(CPU_FTR_SPE))
> + return true;
> +#endif
> + return false;
> +}
Whitespace
> /**
> * kvmppc_handle_exit
> *
> @@ -931,42 +940,71 @@ int kvmppc_handle_exit(struct kvm_run *run,
> struct kvm_vcpu *vcpu,
> r = RESUME_GUEST;
> break;
>
> -#ifdef CONFIG_SPE
> case BOOKE_INTERRUPT_SPE_UNAVAIL: {
> - if (vcpu->arch.shared->msr & MSR_SPE)
> - kvmppc_vcpu_enable_spe(vcpu);
> - else
> - kvmppc_booke_queue_irqprio(vcpu,
> -
> BOOKE_IRQPRIO_SPE_UNAVAIL);
> + /*
> + * The interrupt is shared, KVM support for the
> featured unit
> + * is detected at run-time.
> + */
This is a decent comment for the changelog, but for the code itself it
seems fairly obvious if you look at the definition of
kvmppc_supports_spe().
> + bool handled = false;
> +
> + if (kvmppc_supports_spe()) {
> +#ifdef CONFIG_SPE
> + if (cpu_has_feature(CPU_FTR_SPE))
Didn't you already check this using kvmppc_supports_spe()?
> 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?
-Scott
next prev parent reply other threads:[~2013-06-04 22:14 UTC|newest]
Thread overview: 75+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-06-03 20:54 [RFC PATCH 0/6] KVM: PPC: Book3E: AltiVec support Mihai Caraman
2013-06-03 20:54 ` Mihai Caraman
2013-06-03 20:54 ` Mihai Caraman
2013-06-03 20:54 ` [RFC PATCH 1/6] KVM: PPC: Book3E: Fix AltiVec interrupt numbers and build breakage Mihai Caraman
2013-06-03 20:54 ` Mihai Caraman
2013-06-03 20:54 ` Mihai Caraman
2013-06-03 20:54 ` [RFC PATCH 2/6] KVM: PPC: Book3E: Refactor SPE_FP exit handling Mihai Caraman
2013-06-03 20:54 ` Mihai Caraman
2013-06-03 20:54 ` Mihai Caraman
2013-06-04 22:14 ` Scott Wood [this message]
2013-06-04 22:14 ` Scott Wood
2013-06-04 22:14 ` Scott Wood
2013-06-05 7:29 ` Caraman Mihai Claudiu-B02008
2013-06-05 7:29 ` Caraman Mihai Claudiu-B02008
2013-06-05 7:29 ` Caraman Mihai Claudiu-B02008
2013-06-05 19:07 ` Scott Wood
2013-06-05 19:07 ` Scott Wood
2013-06-05 19:07 ` Scott Wood
2013-06-03 20:54 ` [RFC PATCH 3/6] KVM: PPC: Book3E: Rename IRQPRIO names to accommodate ALTIVEC Mihai Caraman
2013-06-03 20:54 ` Mihai Caraman
2013-06-03 20:54 ` Mihai Caraman
2013-06-04 22:28 ` Scott Wood
2013-06-04 22:28 ` Scott Wood
2013-06-04 22:28 ` Scott Wood
2013-06-05 7:52 ` Caraman Mihai Claudiu-B02008
2013-06-05 7:52 ` Caraman Mihai Claudiu-B02008
2013-06-05 7:52 ` Caraman Mihai Claudiu-B02008
2013-06-03 20:54 ` [RFC PATCH 4/6] KVM: PPC: Book3E: Add AltiVec support Mihai Caraman
2013-06-03 20:54 ` Mihai Caraman
2013-06-03 20:54 ` Mihai Caraman
2013-06-04 22:36 ` Scott Wood
2013-06-04 22:36 ` Scott Wood
2013-06-04 22:36 ` Scott Wood
2013-06-05 9:23 ` Caraman Mihai Claudiu-B02008
2013-06-05 9:23 ` Caraman Mihai Claudiu-B02008
2013-06-05 9:23 ` Caraman Mihai Claudiu-B02008
2013-06-03 20:54 ` [RFC PATCH 5/6] KVM: PPC: Book3E: Add ONE_REG " Mihai Caraman
2013-06-03 20:54 ` Mihai Caraman
2013-06-03 20:54 ` Mihai Caraman
2013-06-04 22:40 ` Scott Wood
2013-06-04 22:40 ` Scott Wood
2013-06-04 22:40 ` Scott Wood
2013-07-03 12:11 ` Caraman Mihai Claudiu-B02008
2013-07-03 12:11 ` Caraman Mihai Claudiu-B02008
2013-07-03 12:11 ` Caraman Mihai Claudiu-B02008
2013-07-03 18:31 ` Scott Wood
2013-07-03 18:31 ` Scott Wood
2013-07-03 18:31 ` Scott Wood
2013-06-03 20:54 ` [RFC PATCH 6/6] KVM: PPC: Book3E: Enhance FPU laziness Mihai Caraman
2013-06-03 20:54 ` Mihai Caraman
2013-06-03 20:54 ` Mihai Caraman
2013-06-04 22:53 ` Scott Wood
2013-06-04 22:53 ` Scott Wood
2013-06-04 22:53 ` Scott Wood
2013-06-05 9:14 ` Caraman Mihai Claudiu-B02008
2013-06-05 9:14 ` Caraman Mihai Claudiu-B02008
2013-06-05 9:14 ` Caraman Mihai Claudiu-B02008
2013-06-05 20:59 ` Scott Wood
2013-06-05 20:59 ` Scott Wood
2013-06-05 20:59 ` Scott Wood
2013-06-04 21:39 ` [RFC PATCH 0/6] KVM: PPC: Book3E: AltiVec support Scott Wood
2013-06-04 21:39 ` Scott Wood
2013-06-04 21:39 ` Scott Wood
2013-06-05 7:10 ` Caraman Mihai Claudiu-B02008
2013-06-05 7:10 ` Caraman Mihai Claudiu-B02008
2013-06-05 7:10 ` Caraman Mihai Claudiu-B02008
2013-06-05 16:35 ` Scott Wood
2013-06-05 16:35 ` Scott Wood
2013-06-05 16:35 ` Scott Wood
2013-06-06 9:42 ` Caraman Mihai Claudiu-B02008
2013-06-06 9:42 ` Caraman Mihai Claudiu-B02008
2013-06-06 9:42 ` Caraman Mihai Claudiu-B02008
2013-06-06 19:57 ` Scott Wood
2013-06-06 19:57 ` Scott Wood
2013-06-06 19:57 ` Scott Wood
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=1370384088.748.17@snotra \
--to=scottwood@freescale.com \
--cc=kvm-ppc@vger.kernel.org \
--cc=kvm@vger.kernel.org \
--cc=linuxppc-dev@lists.ozlabs.org \
--cc=mihai.caraman@freescale.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.