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 4/6] KVM: PPC: Book3E: Add AltiVec support
Date: Tue, 04 Jun 2013 22:36:05 +0000 [thread overview]
Message-ID: <1370385365.748.19@snotra> (raw)
In-Reply-To: <1370292868-2697-5-git-send-email-mihai.caraman@freescale.com> (from mihai.caraman@freescale.com on Mon Jun 3 15:54:26 2013)
On 06/03/2013 03:54:26 PM, Mihai Caraman wrote:
> KVM Book3E FPU support gracefully reuse host infrastructure so we do
> the
> same for AltiVec. To keep AltiVec lazy call
> kvmppc_load_guest_altivec()
> just when returning to guest instead of each sched in.
>
> Signed-off-by: Mihai Caraman <mihai.caraman@freescale.com>
> ---
> arch/powerpc/kvm/booke.c | 74
> +++++++++++++++++++++++++++++++++++++++++++-
> arch/powerpc/kvm/e500mc.c | 8 +++++
> 2 files changed, 80 insertions(+), 2 deletions(-)
>
> diff --git a/arch/powerpc/kvm/booke.c b/arch/powerpc/kvm/booke.c
> index c08b04b..01eb635 100644
> --- a/arch/powerpc/kvm/booke.c
> +++ b/arch/powerpc/kvm/booke.c
> @@ -134,6 +134,23 @@ static void kvmppc_vcpu_sync_fpu(struct kvm_vcpu
> *vcpu)
> }
>
> /*
> + * Simulate AltiVec unavailable fault to load guest state
> + * from thread to AltiVec unit.
> + * It requires to be called with preemption disabled.
> + */
> +static inline void kvmppc_load_guest_altivec(struct kvm_vcpu *vcpu)
> +{
> +#ifdef CONFIG_ALTIVEC
> + if (cpu_has_feature(CPU_FTR_ALTIVEC)) {
> + if (!(current->thread.regs->msr & MSR_VEC)) {
> + load_up_altivec(NULL);
> + current->thread.regs->msr |= MSR_VEC;
> + }
> + }
> +#endif
Why not use kvmppc_supports_altivec()? In fact, there's nothing
KVM-specific about these functions...
> +/*
> + * Always returns true is AltiVec unit is present, see
> + * kvmppc_core_check_processor_compat().
> + */
> +static inline bool kvmppc_supports_altivec(void)
> +{
> +#ifdef CONFIG_ALTIVEC
> + if (cpu_has_feature(CPU_FTR_ALTIVEC))
> + return true;
> +#endif
> + return false;
> +}
Whitespace
> static inline bool kvmppc_supports_spe(void)
> {
> #ifdef CONFIG_SPE
> @@ -947,7 +1016,7 @@ int kvmppc_handle_exit(struct kvm_run *run,
> struct kvm_vcpu *vcpu,
> */
> bool handled = false;
>
> - if (kvmppc_supports_spe()) {
> + if (kvmppc_supports_altivec() || kvmppc_supports_spe())
> {
> #ifdef CONFIG_SPE
> if (cpu_has_feature(CPU_FTR_SPE))
> if (vcpu->arch.shared->msr & MSR_SPE) {
> @@ -976,7 +1045,7 @@ int kvmppc_handle_exit(struct kvm_run *run,
> struct kvm_vcpu *vcpu,
> * The interrupt is shared, KVM support for the
> featured unit
> * is detected at run-time.
> */
> - if (kvmppc_supports_spe()) {
> + if (kvmppc_supports_altivec() || kvmppc_supports_spe())
> {
> kvmppc_booke_queue_irqprio(vcpu,
>
> BOOKE_IRQPRIO_SPE_FP_DATA_ALTIVEC_ASSIST);
> r = RESUME_GUEST;
The distinction between how you're handling SPE and Altivec here
doesn't really have anything to do with SPE versus Altivec -- it's
PR-mode versus HV-mode.
> @@ -1188,6 +1257,7 @@ int kvmppc_handle_exit(struct kvm_run *run,
> struct kvm_vcpu *vcpu,
> r = (s << 2) | RESUME_HOST | (r &
> RESUME_FLAG_NV);
> } else {
> kvmppc_lazy_ee_enable();
> + kvmppc_load_guest_altivec(vcpu);
> }
> }
>
Why do you need to call an Altivec function here if we don't need to
call an ordinary FPU function here?
-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 4/6] KVM: PPC: Book3E: Add AltiVec support
Date: Tue, 4 Jun 2013 17:36:05 -0500 [thread overview]
Message-ID: <1370385365.748.19@snotra> (raw)
In-Reply-To: <1370292868-2697-5-git-send-email-mihai.caraman@freescale.com> (from mihai.caraman@freescale.com on Mon Jun 3 15:54:26 2013)
On 06/03/2013 03:54:26 PM, Mihai Caraman wrote:
> KVM Book3E FPU support gracefully reuse host infrastructure so we do =20
> the
> same for AltiVec. To keep AltiVec lazy call =20
> kvmppc_load_guest_altivec()
> just when returning to guest instead of each sched in.
>=20
> Signed-off-by: Mihai Caraman <mihai.caraman@freescale.com>
> ---
> arch/powerpc/kvm/booke.c | 74 =20
> +++++++++++++++++++++++++++++++++++++++++++-
> arch/powerpc/kvm/e500mc.c | 8 +++++
> 2 files changed, 80 insertions(+), 2 deletions(-)
>=20
> diff --git a/arch/powerpc/kvm/booke.c b/arch/powerpc/kvm/booke.c
> index c08b04b..01eb635 100644
> --- a/arch/powerpc/kvm/booke.c
> +++ b/arch/powerpc/kvm/booke.c
> @@ -134,6 +134,23 @@ static void kvmppc_vcpu_sync_fpu(struct kvm_vcpu =20
> *vcpu)
> }
>=20
> /*
> + * Simulate AltiVec unavailable fault to load guest state
> + * from thread to AltiVec unit.
> + * It requires to be called with preemption disabled.
> + */
> +static inline void kvmppc_load_guest_altivec(struct kvm_vcpu *vcpu)
> +{
> +#ifdef CONFIG_ALTIVEC
> + if (cpu_has_feature(CPU_FTR_ALTIVEC)) {
> + if (!(current->thread.regs->msr & MSR_VEC)) {
> + load_up_altivec(NULL);
> + current->thread.regs->msr |=3D MSR_VEC;
> + }
> + }
> +#endif
Why not use kvmppc_supports_altivec()? In fact, there's nothing =20
KVM-specific about these functions...
> +/*
> + * Always returns true is AltiVec unit is present, see
> + * kvmppc_core_check_processor_compat().
> + */
> +static inline bool kvmppc_supports_altivec(void)
> +{
> +#ifdef CONFIG_ALTIVEC
> + if (cpu_has_feature(CPU_FTR_ALTIVEC))
> + return true;
> +#endif
> + return false;
> +}
Whitespace
> static inline bool kvmppc_supports_spe(void)
> {
> #ifdef CONFIG_SPE
> @@ -947,7 +1016,7 @@ int kvmppc_handle_exit(struct kvm_run *run, =20
> struct kvm_vcpu *vcpu,
> */
> bool handled =3D false;
>=20
> - if (kvmppc_supports_spe()) {
> + if (kvmppc_supports_altivec() || kvmppc_supports_spe()) =20
> {
> #ifdef CONFIG_SPE
> if (cpu_has_feature(CPU_FTR_SPE))
> if (vcpu->arch.shared->msr & MSR_SPE) {
> @@ -976,7 +1045,7 @@ int kvmppc_handle_exit(struct kvm_run *run, =20
> struct kvm_vcpu *vcpu,
> * The interrupt is shared, KVM support for the =20
> featured unit
> * is detected at run-time.
> */
> - if (kvmppc_supports_spe()) {
> + if (kvmppc_supports_altivec() || kvmppc_supports_spe()) =20
> {
> kvmppc_booke_queue_irqprio(vcpu,
> =20
> BOOKE_IRQPRIO_SPE_FP_DATA_ALTIVEC_ASSIST);
> r =3D RESUME_GUEST;
The distinction between how you're handling SPE and Altivec here =20
doesn't really have anything to do with SPE versus Altivec -- it's =20
PR-mode versus HV-mode.
> @@ -1188,6 +1257,7 @@ int kvmppc_handle_exit(struct kvm_run *run, =20
> struct kvm_vcpu *vcpu,
> r =3D (s << 2) | RESUME_HOST | (r & =20
> RESUME_FLAG_NV);
> } else {
> kvmppc_lazy_ee_enable();
> + kvmppc_load_guest_altivec(vcpu);
> }
> }
>=20
Why do you need to call an Altivec function here if we don't need to =20
call an ordinary FPU function here?
-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 4/6] KVM: PPC: Book3E: Add AltiVec support
Date: Tue, 4 Jun 2013 17:36:05 -0500 [thread overview]
Message-ID: <1370385365.748.19@snotra> (raw)
In-Reply-To: <1370292868-2697-5-git-send-email-mihai.caraman@freescale.com> (from mihai.caraman@freescale.com on Mon Jun 3 15:54:26 2013)
On 06/03/2013 03:54:26 PM, Mihai Caraman wrote:
> KVM Book3E FPU support gracefully reuse host infrastructure so we do
> the
> same for AltiVec. To keep AltiVec lazy call
> kvmppc_load_guest_altivec()
> just when returning to guest instead of each sched in.
>
> Signed-off-by: Mihai Caraman <mihai.caraman@freescale.com>
> ---
> arch/powerpc/kvm/booke.c | 74
> +++++++++++++++++++++++++++++++++++++++++++-
> arch/powerpc/kvm/e500mc.c | 8 +++++
> 2 files changed, 80 insertions(+), 2 deletions(-)
>
> diff --git a/arch/powerpc/kvm/booke.c b/arch/powerpc/kvm/booke.c
> index c08b04b..01eb635 100644
> --- a/arch/powerpc/kvm/booke.c
> +++ b/arch/powerpc/kvm/booke.c
> @@ -134,6 +134,23 @@ static void kvmppc_vcpu_sync_fpu(struct kvm_vcpu
> *vcpu)
> }
>
> /*
> + * Simulate AltiVec unavailable fault to load guest state
> + * from thread to AltiVec unit.
> + * It requires to be called with preemption disabled.
> + */
> +static inline void kvmppc_load_guest_altivec(struct kvm_vcpu *vcpu)
> +{
> +#ifdef CONFIG_ALTIVEC
> + if (cpu_has_feature(CPU_FTR_ALTIVEC)) {
> + if (!(current->thread.regs->msr & MSR_VEC)) {
> + load_up_altivec(NULL);
> + current->thread.regs->msr |= MSR_VEC;
> + }
> + }
> +#endif
Why not use kvmppc_supports_altivec()? In fact, there's nothing
KVM-specific about these functions...
> +/*
> + * Always returns true is AltiVec unit is present, see
> + * kvmppc_core_check_processor_compat().
> + */
> +static inline bool kvmppc_supports_altivec(void)
> +{
> +#ifdef CONFIG_ALTIVEC
> + if (cpu_has_feature(CPU_FTR_ALTIVEC))
> + return true;
> +#endif
> + return false;
> +}
Whitespace
> static inline bool kvmppc_supports_spe(void)
> {
> #ifdef CONFIG_SPE
> @@ -947,7 +1016,7 @@ int kvmppc_handle_exit(struct kvm_run *run,
> struct kvm_vcpu *vcpu,
> */
> bool handled = false;
>
> - if (kvmppc_supports_spe()) {
> + if (kvmppc_supports_altivec() || kvmppc_supports_spe())
> {
> #ifdef CONFIG_SPE
> if (cpu_has_feature(CPU_FTR_SPE))
> if (vcpu->arch.shared->msr & MSR_SPE) {
> @@ -976,7 +1045,7 @@ int kvmppc_handle_exit(struct kvm_run *run,
> struct kvm_vcpu *vcpu,
> * The interrupt is shared, KVM support for the
> featured unit
> * is detected at run-time.
> */
> - if (kvmppc_supports_spe()) {
> + if (kvmppc_supports_altivec() || kvmppc_supports_spe())
> {
> kvmppc_booke_queue_irqprio(vcpu,
>
> BOOKE_IRQPRIO_SPE_FP_DATA_ALTIVEC_ASSIST);
> r = RESUME_GUEST;
The distinction between how you're handling SPE and Altivec here
doesn't really have anything to do with SPE versus Altivec -- it's
PR-mode versus HV-mode.
> @@ -1188,6 +1257,7 @@ int kvmppc_handle_exit(struct kvm_run *run,
> struct kvm_vcpu *vcpu,
> r = (s << 2) | RESUME_HOST | (r &
> RESUME_FLAG_NV);
> } else {
> kvmppc_lazy_ee_enable();
> + kvmppc_load_guest_altivec(vcpu);
> }
> }
>
Why do you need to call an Altivec function here if we don't need to
call an ordinary FPU function here?
-Scott
next prev parent reply other threads:[~2013-06-04 22:36 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
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 [this message]
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=1370385365.748.19@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.