From: Scott Wood <scottwood@freescale.com>
To: Caraman Mihai Claudiu-B02008 <B02008@freescale.com>
Cc: Wood Scott-B07421 <B07421@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>,
Alexander Graf <agraf@suse.de>
Subject: Re: [RFC PATCH 6/6] KVM: PPC: Book3E: Enhance FPU laziness
Date: Wed, 05 Jun 2013 20:59:42 +0000 [thread overview]
Message-ID: <1370465982.26139.11@snotra> (raw)
In-Reply-To: <300B73AA675FCE4A93EB4FC1D42459FF44F178@039-SN2MPN1-011.039d.mgd.msft.net> (from B02008@freescale.com on Wed Jun 5 04:14:21 2013)
On 06/05/2013 04:14:21 AM, Caraman Mihai Claudiu-B02008 wrote:
> > -----Original Message-----
> > From: Wood Scott-B07421
> > Sent: Wednesday, June 05, 2013 1:54 AM
> > To: Caraman Mihai Claudiu-B02008
> > Cc: kvm-ppc@vger.kernel.org; kvm@vger.kernel.org; linuxppc-
> > dev@lists.ozlabs.org; Caraman Mihai Claudiu-B02008
> > Subject: Re: [RFC PATCH 6/6] KVM: PPC: Book3E: Enhance FPU laziness
> >
> > On 06/03/2013 03:54:28 PM, Mihai Caraman wrote:
> > > Adopt AltiVec approach to increase laziness by calling
> > > kvmppc_load_guest_fp()
> > > just before returning to guest instaed of each sched in.
> > >
> > > Signed-off-by: Mihai Caraman <mihai.caraman@freescale.com>
> >
> > If you did this *before* adding Altivec it would have saved a
> question
> > in an earlier patch. :-)
>
> I kept asking myself about the order and in the end I decided that
> this is
> an improvement originated from AltiVec work. FPU may be further
> cleaned up
> (get rid of active state, etc).
>
> >
> > > ---
> > > arch/powerpc/kvm/booke.c | 1 +
> > > arch/powerpc/kvm/e500mc.c | 2 --
> > > 2 files changed, 1 insertions(+), 2 deletions(-)
> > >
> > > diff --git a/arch/powerpc/kvm/booke.c b/arch/powerpc/kvm/booke.c
> > > index 019496d..5382238 100644
> > > --- a/arch/powerpc/kvm/booke.c
> > > +++ b/arch/powerpc/kvm/booke.c
> > > @@ -1258,6 +1258,7 @@ int kvmppc_handle_exit(struct kvm_run *run,
> > > struct kvm_vcpu *vcpu,
> > > } else {
> > > kvmppc_lazy_ee_enable();
> > > kvmppc_load_guest_altivec(vcpu);
> > > + kvmppc_load_guest_fp(vcpu);
> > > }
> > > }
> > >
> >
> > You should probably do these before kvmppc_lazy_ee_enable().
>
> Why? I wanted to look like part of lightweight_exit.
We want to minimize the portion of the code that runs with interrupts
disabled while telling tracers that interrupts are enabled. We want to
minimize the C code run with lazy EE in an inconsistent state.
The same applies to kvm_vcpu_run()...
> > Actually, I don't think this is a good idea at all. As I understand
> > it, you're not supposed to take kernel ownersship of floating point
> in
> > non-atomic context, because an interrupt could itself call
> > enable_kernel_fp().
>
> So lightweight_exit isn't executed in atomic context?
Ignore this, I misread what the patch was doing. I thought you were
doing the opposite you did. :-P
As such, this patch appears to fix the thing I was complaining about --
before, we could have taken an interrupt after kvmppc_core_vcpu_load(),
and that interrupt could have claimed the floating point (unlikely with
the kernel as is, but you never know what could happen in the future or
out-of-tree...).
> Will be lazyee fixes including kvmppc_fix_ee_before_entry() in 3.10?
> 64-bit Book3E KVM is unreliable without them. Should we disable e5500
> too
> for 3.10?
I hope so... I meant to ask Gleb to take them while Alex was away, but
I forgot about them. :-P
Alex, are you back from vacation yet?
-Scott
WARNING: multiple messages have this Message-ID (diff)
From: Scott Wood <scottwood@freescale.com>
To: Caraman Mihai Claudiu-B02008 <B02008@freescale.com>
Cc: Wood Scott-B07421 <B07421@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>,
Alexander Graf <agraf@suse.de>
Subject: Re: [RFC PATCH 6/6] KVM: PPC: Book3E: Enhance FPU laziness
Date: Wed, 5 Jun 2013 15:59:42 -0500 [thread overview]
Message-ID: <1370465982.26139.11@snotra> (raw)
In-Reply-To: <300B73AA675FCE4A93EB4FC1D42459FF44F178@039-SN2MPN1-011.039d.mgd.msft.net> (from B02008@freescale.com on Wed Jun 5 04:14:21 2013)
On 06/05/2013 04:14:21 AM, Caraman Mihai Claudiu-B02008 wrote:
> > -----Original Message-----
> > From: Wood Scott-B07421
> > Sent: Wednesday, June 05, 2013 1:54 AM
> > To: Caraman Mihai Claudiu-B02008
> > Cc: kvm-ppc@vger.kernel.org; kvm@vger.kernel.org; linuxppc-
> > dev@lists.ozlabs.org; Caraman Mihai Claudiu-B02008
> > Subject: Re: [RFC PATCH 6/6] KVM: PPC: Book3E: Enhance FPU laziness
> >
> > On 06/03/2013 03:54:28 PM, Mihai Caraman wrote:
> > > Adopt AltiVec approach to increase laziness by calling
> > > kvmppc_load_guest_fp()
> > > just before returning to guest instaed of each sched in.
> > >
> > > Signed-off-by: Mihai Caraman <mihai.caraman@freescale.com>
> >
> > If you did this *before* adding Altivec it would have saved a =20
> question
> > in an earlier patch. :-)
>=20
> I kept asking myself about the order and in the end I decided that =20
> this is
> an improvement originated from AltiVec work. FPU may be further =20
> cleaned up
> (get rid of active state, etc).
>=20
> >
> > > ---
> > > arch/powerpc/kvm/booke.c | 1 +
> > > arch/powerpc/kvm/e500mc.c | 2 --
> > > 2 files changed, 1 insertions(+), 2 deletions(-)
> > >
> > > diff --git a/arch/powerpc/kvm/booke.c b/arch/powerpc/kvm/booke.c
> > > index 019496d..5382238 100644
> > > --- a/arch/powerpc/kvm/booke.c
> > > +++ b/arch/powerpc/kvm/booke.c
> > > @@ -1258,6 +1258,7 @@ int kvmppc_handle_exit(struct kvm_run *run,
> > > struct kvm_vcpu *vcpu,
> > > } else {
> > > kvmppc_lazy_ee_enable();
> > > kvmppc_load_guest_altivec(vcpu);
> > > + kvmppc_load_guest_fp(vcpu);
> > > }
> > > }
> > >
> >
> > You should probably do these before kvmppc_lazy_ee_enable().
>=20
> Why? I wanted to look like part of lightweight_exit.
We want to minimize the portion of the code that runs with interrupts =20
disabled while telling tracers that interrupts are enabled. We want to =20
minimize the C code run with lazy EE in an inconsistent state.
The same applies to kvm_vcpu_run()...
> > Actually, I don't think this is a good idea at all. As I understand
> > it, you're not supposed to take kernel ownersship of floating point =20
> in
> > non-atomic context, because an interrupt could itself call
> > enable_kernel_fp().
>=20
> So lightweight_exit isn't executed in atomic context?
Ignore this, I misread what the patch was doing. I thought you were =20
doing the opposite you did. :-P
As such, this patch appears to fix the thing I was complaining about -- =20
before, we could have taken an interrupt after kvmppc_core_vcpu_load(), =20
and that interrupt could have claimed the floating point (unlikely with =20
the kernel as is, but you never know what could happen in the future or =20
out-of-tree...).
> Will be lazyee fixes including kvmppc_fix_ee_before_entry() in 3.10?
> 64-bit Book3E KVM is unreliable without them. Should we disable e5500 =20
> too
> for 3.10?
I hope so... I meant to ask Gleb to take them while Alex was away, but =20
I forgot about them. :-P
Alex, are you back from vacation yet?
-Scott=
WARNING: multiple messages have this Message-ID (diff)
From: Scott Wood <scottwood@freescale.com>
To: Caraman Mihai Claudiu-B02008 <B02008@freescale.com>
Cc: Wood Scott-B07421 <B07421@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>,
Alexander Graf <agraf@suse.de>
Subject: Re: [RFC PATCH 6/6] KVM: PPC: Book3E: Enhance FPU laziness
Date: Wed, 5 Jun 2013 15:59:42 -0500 [thread overview]
Message-ID: <1370465982.26139.11@snotra> (raw)
In-Reply-To: <300B73AA675FCE4A93EB4FC1D42459FF44F178@039-SN2MPN1-011.039d.mgd.msft.net> (from B02008@freescale.com on Wed Jun 5 04:14:21 2013)
On 06/05/2013 04:14:21 AM, Caraman Mihai Claudiu-B02008 wrote:
> > -----Original Message-----
> > From: Wood Scott-B07421
> > Sent: Wednesday, June 05, 2013 1:54 AM
> > To: Caraman Mihai Claudiu-B02008
> > Cc: kvm-ppc@vger.kernel.org; kvm@vger.kernel.org; linuxppc-
> > dev@lists.ozlabs.org; Caraman Mihai Claudiu-B02008
> > Subject: Re: [RFC PATCH 6/6] KVM: PPC: Book3E: Enhance FPU laziness
> >
> > On 06/03/2013 03:54:28 PM, Mihai Caraman wrote:
> > > Adopt AltiVec approach to increase laziness by calling
> > > kvmppc_load_guest_fp()
> > > just before returning to guest instaed of each sched in.
> > >
> > > Signed-off-by: Mihai Caraman <mihai.caraman@freescale.com>
> >
> > If you did this *before* adding Altivec it would have saved a
> question
> > in an earlier patch. :-)
>
> I kept asking myself about the order and in the end I decided that
> this is
> an improvement originated from AltiVec work. FPU may be further
> cleaned up
> (get rid of active state, etc).
>
> >
> > > ---
> > > arch/powerpc/kvm/booke.c | 1 +
> > > arch/powerpc/kvm/e500mc.c | 2 --
> > > 2 files changed, 1 insertions(+), 2 deletions(-)
> > >
> > > diff --git a/arch/powerpc/kvm/booke.c b/arch/powerpc/kvm/booke.c
> > > index 019496d..5382238 100644
> > > --- a/arch/powerpc/kvm/booke.c
> > > +++ b/arch/powerpc/kvm/booke.c
> > > @@ -1258,6 +1258,7 @@ int kvmppc_handle_exit(struct kvm_run *run,
> > > struct kvm_vcpu *vcpu,
> > > } else {
> > > kvmppc_lazy_ee_enable();
> > > kvmppc_load_guest_altivec(vcpu);
> > > + kvmppc_load_guest_fp(vcpu);
> > > }
> > > }
> > >
> >
> > You should probably do these before kvmppc_lazy_ee_enable().
>
> Why? I wanted to look like part of lightweight_exit.
We want to minimize the portion of the code that runs with interrupts
disabled while telling tracers that interrupts are enabled. We want to
minimize the C code run with lazy EE in an inconsistent state.
The same applies to kvm_vcpu_run()...
> > Actually, I don't think this is a good idea at all. As I understand
> > it, you're not supposed to take kernel ownersship of floating point
> in
> > non-atomic context, because an interrupt could itself call
> > enable_kernel_fp().
>
> So lightweight_exit isn't executed in atomic context?
Ignore this, I misread what the patch was doing. I thought you were
doing the opposite you did. :-P
As such, this patch appears to fix the thing I was complaining about --
before, we could have taken an interrupt after kvmppc_core_vcpu_load(),
and that interrupt could have claimed the floating point (unlikely with
the kernel as is, but you never know what could happen in the future or
out-of-tree...).
> Will be lazyee fixes including kvmppc_fix_ee_before_entry() in 3.10?
> 64-bit Book3E KVM is unreliable without them. Should we disable e5500
> too
> for 3.10?
I hope so... I meant to ask Gleb to take them while Alex was away, but
I forgot about them. :-P
Alex, are you back from vacation yet?
-Scott
next prev parent reply other threads:[~2013-06-05 20:59 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
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 [this message]
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=1370465982.26139.11@snotra \
--to=scottwood@freescale.com \
--cc=B02008@freescale.com \
--cc=B07421@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.