RE: [RFC PATCH 6/6] KVM: PPC: Book3E: Enhance FPU laziness
-Original Message-
From: Wood Scott-B07421
Sent: Wednesday, June 05, 2013 1:54 AM
To: Caraman Mihai Claudiu-B02008
Cc: kvm-...@vger.kernel.org; kvm@vger.kernel.org; linuxppc-
d...@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.cara...@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.
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?
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?
Do you have benchmarks showing it's even worthwhile?
No yet but isn't this the whole idea of FPU/AltiVec laziness that the kernel
is struggling to achieve? Without it when returning to host (if another process
got unit ownership in handle_exit) we restore and save the unit state for
nothing.
This multiplies when the ownership goes back and forth between handle_exit and
other
processes.
Do you have in mid a specific AltiVec benchmark? I have a stress application
that do
consecutive vector assignments which proved to be very good at finding state
corruptions. If I combine this application on the host with a guest that stays
longer
on handle_exit (running a tlb or emulation intensive application) I might have
good
data to support my case.
-Mike
-Scott
--
To unsubscribe from this list: send the line unsubscribe kvm in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC PATCH 6/6] KVM: PPC: Book3E: Enhance FPU laziness
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-...@vger.kernel.org; kvm@vger.kernel.org; linuxppc-
d...@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.cara...@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
--
To unsubscribe from this list: send the line unsubscribe kvm in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
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.cara...@freescale.com
If you did this *before* adding Altivec it would have saved a question
in an earlier patch. :-)
---
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().
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().
Do you have benchmarks showing it's even worthwhile?
-Scott
--
To unsubscribe from this list: send the line unsubscribe kvm in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
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.cara...@freescale.com
If you did this *before* adding Altivec it would have saved a question
in an earlier patch. :-)
---
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().
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().
Do you have benchmarks showing it's even worthwhile?
-Scott
--
To unsubscribe from this list: send the line unsubscribe kvm-ppc in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[RFC PATCH 6/6] KVM: PPC: Book3E: Enhance FPU laziness
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.cara...@freescale.com
---
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);
}
}
diff --git a/arch/powerpc/kvm/e500mc.c b/arch/powerpc/kvm/e500mc.c
index 9d7f38e..29cf97a 100644
--- a/arch/powerpc/kvm/e500mc.c
+++ b/arch/powerpc/kvm/e500mc.c
@@ -138,8 +138,6 @@ void kvmppc_core_vcpu_load(struct kvm_vcpu *vcpu, int cpu)
if (vcpu-arch.oldpir != mfspr(SPRN_PIR))
kvmppc_e500_tlbil_all(vcpu_e500);
-
- kvmppc_load_guest_fp(vcpu);
}
void kvmppc_core_vcpu_put(struct kvm_vcpu *vcpu)
--
1.7.4.1
--
To unsubscribe from this list: send the line unsubscribe kvm in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
