diff for duplicates of <1370465982.26139.11@snotra> diff --git a/a/1.txt b/N1/1.txt index 2be305a..49f0b9d 100644 --- a/a/1.txt +++ b/N1/1.txt @@ -14,16 +14,16 @@ On 06/05/2013 04:14:21 AM, Caraman Mihai Claudiu-B02008 wrote: > > > > > > Signed-off-by: Mihai Caraman <mihai.caraman@freescale.com> > > -> > If you did this *before* adding Altivec it would have saved a +> > If you did this *before* adding Altivec it would have saved a =20 > question > > in an earlier patch. :-) -> -> I kept asking myself about the order and in the end I decided that +>=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 +> 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 + @@ -45,40 +45,40 @@ On 06/05/2013 04:14:21 AM, Caraman Mihai Claudiu-B02008 wrote: > > > > > > > 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 -disabled while telling tracers that interrupts are enabled. We want to +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 +> > 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 +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 -- -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 +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 +> 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 +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 +-Scott= diff --git a/a/content_digest b/N1/content_digest index 4a2930d..54a7aa8 100644 --- a/a/content_digest +++ b/N1/content_digest @@ -1,12 +1,12 @@ "ref\0300B73AA675FCE4A93EB4FC1D42459FF44F178@039-SN2MPN1-011.039d.mgd.msft.net\0" "From\0Scott Wood <scottwood@freescale.com>\0" "Subject\0Re: [RFC PATCH 6/6] KVM: PPC: Book3E: Enhance FPU laziness\0" - "Date\0Wed, 05 Jun 2013 20:59:42 +0000\0" + "Date\0Wed, 5 Jun 2013 15:59:42 -0500\0" "To\0Caraman Mihai Claudiu-B02008 <B02008@freescale.com>\0" "Cc\0Wood 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> + kvm@vger.kernel.org <kvm@vger.kernel.org> + kvm-ppc@vger.kernel.org <kvm-ppc@vger.kernel.org> " Alexander Graf <agraf@suse.de>\0" "\00:1\0" "b\0" @@ -26,16 +26,16 @@ "> > >\n" "> > > Signed-off-by: Mihai Caraman <mihai.caraman@freescale.com>\n" "> >\n" - "> > If you did this *before* adding Altivec it would have saved a \n" + "> > If you did this *before* adding Altivec it would have saved a =20\n" "> question\n" "> > in an earlier patch. :-)\n" - "> \n" - "> I kept asking myself about the order and in the end I decided that \n" + ">=20\n" + "> I kept asking myself about the order and in the end I decided that =20\n" "> this is\n" - "> an improvement originated from AltiVec work. FPU may be further \n" + "> an improvement originated from AltiVec work. FPU may be further =20\n" "> cleaned up\n" "> (get rid of active state, etc).\n" - "> \n" + ">=20\n" "> >\n" "> > > ---\n" "> > > arch/powerpc/kvm/booke.c | 1 +\n" @@ -57,42 +57,42 @@ "> > >\n" "> >\n" "> > You should probably do these before kvmppc_lazy_ee_enable().\n" - "> \n" + ">=20\n" "> Why? I wanted to look like part of lightweight_exit.\n" "\n" - "We want to minimize the portion of the code that runs with interrupts \n" - "disabled while telling tracers that interrupts are enabled. We want to \n" + "We want to minimize the portion of the code that runs with interrupts =20\n" + "disabled while telling tracers that interrupts are enabled. We want to =20\n" "minimize the C code run with lazy EE in an inconsistent state.\n" "\n" "The same applies to kvm_vcpu_run()...\n" "\n" "> > Actually, I don't think this is a good idea at all. As I understand\n" - "> > it, you're not supposed to take kernel ownersship of floating point \n" + "> > it, you're not supposed to take kernel ownersship of floating point =20\n" "> in\n" "> > non-atomic context, because an interrupt could itself call\n" "> > enable_kernel_fp().\n" - "> \n" + ">=20\n" "> So lightweight_exit isn't executed in atomic context?\n" "\n" - "Ignore this, I misread what the patch was doing. I thought you were \n" + "Ignore this, I misread what the patch was doing. I thought you were =20\n" "doing the opposite you did. :-P\n" "\n" - "As such, this patch appears to fix the thing I was complaining about -- \n" - "before, we could have taken an interrupt after kvmppc_core_vcpu_load(), \n" - "and that interrupt could have claimed the floating point (unlikely with \n" - "the kernel as is, but you never know what could happen in the future or \n" + "As such, this patch appears to fix the thing I was complaining about -- =20\n" + "before, we could have taken an interrupt after kvmppc_core_vcpu_load(), =20\n" + "and that interrupt could have claimed the floating point (unlikely with =20\n" + "the kernel as is, but you never know what could happen in the future or =20\n" "out-of-tree...).\n" "\n" "> Will be lazyee fixes including kvmppc_fix_ee_before_entry() in 3.10?\n" - "> 64-bit Book3E KVM is unreliable without them. Should we disable e5500 \n" + "> 64-bit Book3E KVM is unreliable without them. Should we disable e5500 =20\n" "> too\n" "> for 3.10?\n" "\n" - "I hope so... I meant to ask Gleb to take them while Alex was away, but \n" + "I hope so... I meant to ask Gleb to take them while Alex was away, but =20\n" "I forgot about them. :-P\n" "\n" "Alex, are you back from vacation yet?\n" "\n" - -Scott + -Scott= -44df60225bef2a23696e313cd67ab8d46a9865977e64a3287433f231c11fd387 +9bbf55441d5ce8f516eedbcc2887e076aed69d2b61fe59c5b77c73a9d9415587
diff --git a/a/content_digest b/N2/content_digest index 4a2930d..3bfd44d 100644 --- a/a/content_digest +++ b/N2/content_digest @@ -1,7 +1,7 @@ "ref\0300B73AA675FCE4A93EB4FC1D42459FF44F178@039-SN2MPN1-011.039d.mgd.msft.net\0" "From\0Scott Wood <scottwood@freescale.com>\0" "Subject\0Re: [RFC PATCH 6/6] KVM: PPC: Book3E: Enhance FPU laziness\0" - "Date\0Wed, 05 Jun 2013 20:59:42 +0000\0" + "Date\0Wed, 5 Jun 2013 15:59:42 -0500\0" "To\0Caraman Mihai Claudiu-B02008 <B02008@freescale.com>\0" "Cc\0Wood Scott-B07421 <B07421@freescale.com>" kvm-ppc@vger.kernel.org <kvm-ppc@vger.kernel.org> @@ -95,4 +95,4 @@ "\n" -Scott -44df60225bef2a23696e313cd67ab8d46a9865977e64a3287433f231c11fd387 +eebf88a8d5a0cd0b33dfed96be57b2c773514b8b3421a2209c77568076b64766
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.