From: Scott Wood <scottwood@freescale.com>
To: Alexander Graf <agraf@suse.de>
Cc: Caraman Mihai Claudiu-B02008 <B02008@freescale.com>,
"kvm-ppc@vger.kernel.org" <kvm-ppc@vger.kernel.org>,
"kvm@vger.kernel.org" <kvm@vger.kernel.org>,
"linuxppc-dev@lists.ozlabs.org" <linuxppc-dev@lists.ozlabs.org>
Subject: Re: [PATCH 2/6] KVM: PPC: Book3E: Refactor SPE/FP exit handling
Date: Wed, 03 Jul 2013 18:44:33 +0000 [thread overview]
Message-ID: <1372877073.8183.140@snotra> (raw)
In-Reply-To: <5BA99D8C-1B46-472C-97F7-4A174A39A6D7@suse.de> (from agraf@suse.de on Wed Jul 3 13:42:12 2013)
On 07/03/2013 01:42:12 PM, Alexander Graf wrote:
>
> On 03.07.2013, at 20:28, Scott Wood wrote:
>
> > On 07/03/2013 10:13:57 AM, Alexander Graf wrote:
> >> There is no chip that supports SPE and HV at the same time. So
> we'll never hit this anyway, since kvmppc_supports_spe() always
> returns false on HV capable systems.
> >> Just add a comment saying so and remove the ifdef :).
> >
> > kvmppc_vcpu_enable_spe isn't defined unless CONFIG_SPE is defined.
> More seriously, MSR_SPE is the same as MSR_VEC, so we shouldn't
> interpret it as SPE unless CONFIG_SPE is defined. And we can't rely
> on the "if (kvmppc_supports_spe())" here because a later patch
> changes it to "if (kvmppc_supports_altivec() ||
> kvmppc_supports_spe())". So I think we still need the ifdef
> CONFIG_SPE here.
> >
> > As for the HV ifndef, we should try not to confuse HV/PR with
> e500mc/e500v2, even if we happen to only run HV on e500mc and PR on
> e500v2. We would not want to call kvmppc_vcpu_enable_spe() here on a
> hypothetical HV target with SPE. And we *would* want to call
> kvmppc_vcpu_enable_fp() here on a hypothetical PR target with normal
> FP. It's one thing to leave out the latter, since it would involve
> writing actual code that we have no way to test at this point, but
> quite another to leave out the proper conditions for when we want to
> run code that we do have.
>
> So we should make this an #ifdef CONFIG_SPE rather than #ifndef
> CONFIG_KVM_BOOKE_HV?
I think it should be "#if !defined(CONFIG_KVM_BOOKE_HV) &&
defined(CONFIG_SPE)" for the reasons I described in my second paragraph.
-Scott
WARNING: multiple messages have this Message-ID (diff)
From: Scott Wood <scottwood@freescale.com>
To: Alexander Graf <agraf@suse.de>
Cc: Caraman Mihai Claudiu-B02008 <B02008@freescale.com>,
"linuxppc-dev@lists.ozlabs.org" <linuxppc-dev@lists.ozlabs.org>,
"kvm@vger.kernel.org" <kvm@vger.kernel.org>,
"kvm-ppc@vger.kernel.org" <kvm-ppc@vger.kernel.org>
Subject: Re: [PATCH 2/6] KVM: PPC: Book3E: Refactor SPE/FP exit handling
Date: Wed, 3 Jul 2013 13:44:33 -0500 [thread overview]
Message-ID: <1372877073.8183.140@snotra> (raw)
In-Reply-To: <5BA99D8C-1B46-472C-97F7-4A174A39A6D7@suse.de> (from agraf@suse.de on Wed Jul 3 13:42:12 2013)
On 07/03/2013 01:42:12 PM, Alexander Graf wrote:
>=20
> On 03.07.2013, at 20:28, Scott Wood wrote:
>=20
> > On 07/03/2013 10:13:57 AM, Alexander Graf wrote:
> >> There is no chip that supports SPE and HV at the same time. So =20
> we'll never hit this anyway, since kvmppc_supports_spe() always =20
> returns false on HV capable systems.
> >> Just add a comment saying so and remove the ifdef :).
> >
> > kvmppc_vcpu_enable_spe isn't defined unless CONFIG_SPE is defined. =20
> More seriously, MSR_SPE is the same as MSR_VEC, so we shouldn't =20
> interpret it as SPE unless CONFIG_SPE is defined. And we can't rely =20
> on the "if (kvmppc_supports_spe())" here because a later patch =20
> changes it to "if (kvmppc_supports_altivec() || =20
> kvmppc_supports_spe())". So I think we still need the ifdef =20
> CONFIG_SPE here.
> >
> > As for the HV ifndef, we should try not to confuse HV/PR with =20
> e500mc/e500v2, even if we happen to only run HV on e500mc and PR on =20
> e500v2. We would not want to call kvmppc_vcpu_enable_spe() here on a =20
> hypothetical HV target with SPE. And we *would* want to call =20
> kvmppc_vcpu_enable_fp() here on a hypothetical PR target with normal =20
> FP. It's one thing to leave out the latter, since it would involve =20
> writing actual code that we have no way to test at this point, but =20
> quite another to leave out the proper conditions for when we want to =20
> run code that we do have.
>=20
> So we should make this an #ifdef CONFIG_SPE rather than #ifndef =20
> CONFIG_KVM_BOOKE_HV?
I think it should be "#if !defined(CONFIG_KVM_BOOKE_HV) && =20
defined(CONFIG_SPE)" for the reasons I described in my second paragraph.
-Scott=
WARNING: multiple messages have this Message-ID (diff)
From: Scott Wood <scottwood@freescale.com>
To: Alexander Graf <agraf@suse.de>
Cc: Caraman Mihai Claudiu-B02008 <B02008@freescale.com>,
"kvm-ppc@vger.kernel.org" <kvm-ppc@vger.kernel.org>,
"kvm@vger.kernel.org" <kvm@vger.kernel.org>,
"linuxppc-dev@lists.ozlabs.org" <linuxppc-dev@lists.ozlabs.org>
Subject: Re: [PATCH 2/6] KVM: PPC: Book3E: Refactor SPE/FP exit handling
Date: Wed, 3 Jul 2013 13:44:33 -0500 [thread overview]
Message-ID: <1372877073.8183.140@snotra> (raw)
In-Reply-To: <5BA99D8C-1B46-472C-97F7-4A174A39A6D7@suse.de> (from agraf@suse.de on Wed Jul 3 13:42:12 2013)
On 07/03/2013 01:42:12 PM, Alexander Graf wrote:
>
> On 03.07.2013, at 20:28, Scott Wood wrote:
>
> > On 07/03/2013 10:13:57 AM, Alexander Graf wrote:
> >> There is no chip that supports SPE and HV at the same time. So
> we'll never hit this anyway, since kvmppc_supports_spe() always
> returns false on HV capable systems.
> >> Just add a comment saying so and remove the ifdef :).
> >
> > kvmppc_vcpu_enable_spe isn't defined unless CONFIG_SPE is defined.
> More seriously, MSR_SPE is the same as MSR_VEC, so we shouldn't
> interpret it as SPE unless CONFIG_SPE is defined. And we can't rely
> on the "if (kvmppc_supports_spe())" here because a later patch
> changes it to "if (kvmppc_supports_altivec() ||
> kvmppc_supports_spe())". So I think we still need the ifdef
> CONFIG_SPE here.
> >
> > As for the HV ifndef, we should try not to confuse HV/PR with
> e500mc/e500v2, even if we happen to only run HV on e500mc and PR on
> e500v2. We would not want to call kvmppc_vcpu_enable_spe() here on a
> hypothetical HV target with SPE. And we *would* want to call
> kvmppc_vcpu_enable_fp() here on a hypothetical PR target with normal
> FP. It's one thing to leave out the latter, since it would involve
> writing actual code that we have no way to test at this point, but
> quite another to leave out the proper conditions for when we want to
> run code that we do have.
>
> So we should make this an #ifdef CONFIG_SPE rather than #ifndef
> CONFIG_KVM_BOOKE_HV?
I think it should be "#if !defined(CONFIG_KVM_BOOKE_HV) &&
defined(CONFIG_SPE)" for the reasons I described in my second paragraph.
-Scott
next prev parent reply other threads:[~2013-07-03 18:44 UTC|newest]
Thread overview: 111+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-07-03 12:42 [PATCH 0/6] KVM: PPC: Book3E: AltiVec support Mihai Caraman
2013-07-03 12:42 ` Mihai Caraman
2013-07-03 12:42 ` Mihai Caraman
2013-07-03 12:42 ` [PATCH 1/6] KVM: PPC: Book3E: Use common defines for SPE/FP/AltiVec int numbers Mihai Caraman
2013-07-03 12:42 ` Mihai Caraman
2013-07-03 12:42 ` Mihai Caraman
2013-07-03 12:42 ` [PATCH 2/6] KVM: PPC: Book3E: Refactor SPE/FP exit handling Mihai Caraman
2013-07-03 12:42 ` Mihai Caraman
2013-07-03 12:42 ` Mihai Caraman
2013-07-03 13:30 ` Alexander Graf
2013-07-03 13:30 ` Alexander Graf
2013-07-03 13:30 ` Alexander Graf
2013-07-03 13:53 ` Caraman Mihai Claudiu-B02008
2013-07-03 13:53 ` Caraman Mihai Claudiu-B02008
2013-07-03 13:53 ` Caraman Mihai Claudiu-B02008
2013-07-03 15:13 ` Alexander Graf
2013-07-03 15:13 ` Alexander Graf
2013-07-03 15:13 ` Alexander Graf
2013-07-03 18:28 ` Scott Wood
2013-07-03 18:28 ` Scott Wood
2013-07-03 18:28 ` Scott Wood
2013-07-03 18:42 ` Alexander Graf
2013-07-03 18:42 ` Alexander Graf
2013-07-03 18:42 ` Alexander Graf
2013-07-03 18:44 ` Scott Wood [this message]
2013-07-03 18:44 ` Scott Wood
2013-07-03 18:44 ` Scott Wood
2013-07-03 12:42 ` [PATCH 3/6] KVM: PPC: Book3E: Increase FPU laziness Mihai Caraman
2013-07-03 12:42 ` Mihai Caraman
2013-07-03 12:42 ` Mihai Caraman
2013-07-03 13:45 ` Alexander Graf
2013-07-03 13:45 ` Alexander Graf
2013-07-03 13:45 ` Alexander Graf
2013-07-03 13:55 ` Caraman Mihai Claudiu-B02008
2013-07-03 13:55 ` Caraman Mihai Claudiu-B02008
2013-07-03 13:55 ` Caraman Mihai Claudiu-B02008
2013-07-03 15:11 ` Alexander Graf
2013-07-03 15:11 ` Alexander Graf
2013-07-03 15:11 ` Alexander Graf
2013-07-03 15:41 ` Caraman Mihai Claudiu-B02008
2013-07-03 15:41 ` Caraman Mihai Claudiu-B02008
2013-07-03 15:41 ` Caraman Mihai Claudiu-B02008
2013-07-03 16:59 ` Alexander Graf
2013-07-03 16:59 ` Alexander Graf
2013-07-03 16:59 ` Alexander Graf
2013-07-03 17:17 ` Scott Wood
2013-07-03 17:17 ` Scott Wood
2013-07-03 17:17 ` Scott Wood
2013-07-03 17:22 ` Alexander Graf
2013-07-03 17:22 ` Alexander Graf
2013-07-03 17:22 ` Alexander Graf
2013-07-03 17:07 ` Scott Wood
2013-07-03 17:07 ` Scott Wood
2013-07-03 17:07 ` Scott Wood
2013-07-03 17:08 ` Alexander Graf
2013-07-03 17:08 ` Alexander Graf
2013-07-03 17:08 ` Alexander Graf
2013-07-03 17:18 ` Scott Wood
2013-07-03 17:18 ` Scott Wood
2013-07-03 17:18 ` Scott Wood
2013-07-03 17:23 ` Alexander Graf
2013-07-03 17:23 ` Alexander Graf
2013-07-03 17:23 ` Alexander Graf
2013-07-03 17:44 ` Scott Wood
2013-07-03 17:44 ` Scott Wood
2013-07-03 17:44 ` Scott Wood
2013-07-03 18:39 ` Alexander Graf
2013-07-03 18:39 ` Alexander Graf
2013-07-03 18:39 ` Alexander Graf
2013-07-03 18:37 ` Scott Wood
2013-07-03 18:37 ` Scott Wood
2013-07-03 18:37 ` Scott Wood
2013-07-03 18:40 ` Alexander Graf
2013-07-03 18:40 ` Alexander Graf
2013-07-03 18:40 ` Alexander Graf
2013-07-04 6:50 ` Caraman Mihai Claudiu-B02008
2013-07-04 6:50 ` Caraman Mihai Claudiu-B02008
2013-07-04 6:50 ` Caraman Mihai Claudiu-B02008
2013-07-03 12:42 ` [PATCH 4/6] KVM: PPC: Book3E: Add AltiVec support Mihai Caraman
2013-07-03 12:42 ` Mihai Caraman
2013-07-03 12:42 ` Mihai Caraman
2013-07-03 15:17 ` Alexander Graf
2013-07-03 15:17 ` Alexander Graf
2013-07-03 15:17 ` Alexander Graf
2013-07-03 16:09 ` Caraman Mihai Claudiu-B02008
2013-07-03 16:09 ` Caraman Mihai Claudiu-B02008
2013-07-03 16:09 ` Caraman Mihai Claudiu-B02008
2013-07-03 16:43 ` Alexander Graf
2013-07-03 16:43 ` Alexander Graf
2013-07-03 16:43 ` Alexander Graf
2013-07-03 16:49 ` Caraman Mihai Claudiu-B02008
2013-07-03 16:49 ` Caraman Mihai Claudiu-B02008
2013-07-03 16:49 ` Caraman Mihai Claudiu-B02008
2013-07-03 17:07 ` Alexander Graf
2013-07-03 17:07 ` Alexander Graf
2013-07-03 17:07 ` Alexander Graf
2013-07-03 18:36 ` Scott Wood
2013-07-03 18:36 ` Scott Wood
2013-07-03 18:36 ` Scott Wood
2013-07-03 18:45 ` Alexander Graf
2013-07-03 18:45 ` Alexander Graf
2013-07-03 18:45 ` Alexander Graf
2013-07-03 18:38 ` Scott Wood
2013-07-03 18:38 ` Scott Wood
2013-07-03 18:38 ` Scott Wood
2013-07-03 12:42 ` [PATCH 5/6] KVM: PPC: Book3E: Add ONE_REG " Mihai Caraman
2013-07-03 12:42 ` Mihai Caraman
2013-07-03 12:42 ` Mihai Caraman
2013-07-03 12:42 ` [PATCH 6/6] KVM: PPC: Book3E: Enable e6500 core Mihai Caraman
2013-07-03 12:42 ` Mihai Caraman
2013-07-03 12:42 ` Mihai Caraman
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=1372877073.8183.140@snotra \
--to=scottwood@freescale.com \
--cc=B02008@freescale.com \
--cc=agraf@suse.de \
--cc=kvm-ppc@vger.kernel.org \
--cc=kvm@vger.kernel.org \
--cc=linuxppc-dev@lists.ozlabs.org \
/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.