All of lore.kernel.org
 help / color / mirror / Atom feed
diff for duplicates of <1372876575.8183.137@snotra>

diff --git a/a/1.txt b/N1/1.txt
index 5a96bff..6b76339 100644
--- a/a/1.txt
+++ b/N1/1.txt
@@ -1,8 +1,8 @@
 On 07/03/2013 12:07:30 PM, Alexander Graf wrote:
-> 
+>=20
 > On 03.07.2013, at 18:49, Caraman Mihai Claudiu-B02008 wrote:
-> 
-> >>>> Do we need to do this even when the guest doesn't use Altivec?  
+>=20
+> >>>> Do we need to do this even when the guest doesn't use Altivec? =20
 > Can't
 > >> we
 > >>>> just load it on demand then once we fault? This code path really
@@ -12,21 +12,21 @@ On 07/03/2013 12:07:30 PM, Alexander Graf wrote:
 > >>>
 > >>> No we can't, read 6/6.
 > >>
-> >> So we have to make sure we're completely unlazy when it comes to a  
+> >> So we have to make sure we're completely unlazy when it comes to a =20
 > KVM
 > >> guest. Are we?
 > >
 > > Yes, because MSR[SPV] is under its control.
-> 
-> Oh, sure, KVM wants it unlazy. That part is obvious. But does the  
-> kernel always give us unlazyness? The way I read the code, process.c  
+>=20
+> Oh, sure, KVM wants it unlazy. That part is obvious. But does the =20
+> kernel always give us unlazyness? The way I read the code, process.c =20
 > goes lazy when !CONFIG_SMP.
-> 
-> So the big question is why we're manually enforcing FPU giveup, but  
+>=20
+> So the big question is why we're manually enforcing FPU giveup, but =20
 > not Altivec giveup? One of the 2 probably is wrong :).
 
-Why do you think we're not enforcing it for Altivec?  Is there some  
-specific piece of code you're referring to that is different in this  
+Why do you think we're not enforcing it for Altivec?  Is there some =20
+specific piece of code you're referring to that is different in this =20
 regard?
 
--Scott
+-Scott=
diff --git a/a/content_digest b/N1/content_digest
index 6f0d7bf..9141358 100644
--- a/a/content_digest
+++ b/N1/content_digest
@@ -7,19 +7,19 @@
  "ref\0098F899F-54BF-4172-958B-C52C015F5142@suse.de\0"
  "From\0Scott Wood <scottwood@freescale.com>\0"
  "Subject\0Re: [PATCH 4/6] KVM: PPC: Book3E: Add AltiVec support\0"
- "Date\0Wed, 03 Jul 2013 18:36:15 +0000\0"
+ "Date\0Wed, 3 Jul 2013 13:36:15 -0500\0"
  "To\0Alexander Graf <agraf@suse.de>\0"
  "Cc\0Caraman Mihai Claudiu-B02008 <B02008@freescale.com>"
-  kvm-ppc@vger.kernel.org <kvm-ppc@vger.kernel.org>
+  linuxppc-dev@lists.ozlabs.org <linuxppc-dev@lists.ozlabs.org>
   kvm@vger.kernel.org <kvm@vger.kernel.org>
- " linuxppc-dev@lists.ozlabs.org <linuxppc-dev@lists.ozlabs.org>\0"
+ " kvm-ppc@vger.kernel.org <kvm-ppc@vger.kernel.org>\0"
  "\00:1\0"
  "b\0"
  "On 07/03/2013 12:07:30 PM, Alexander Graf wrote:\n"
- "> \n"
+ ">=20\n"
  "> On 03.07.2013, at 18:49, Caraman Mihai Claudiu-B02008 wrote:\n"
- "> \n"
- "> >>>> Do we need to do this even when the guest doesn't use Altivec?  \n"
+ ">=20\n"
+ "> >>>> Do we need to do this even when the guest doesn't use Altivec? =20\n"
  "> Can't\n"
  "> >> we\n"
  "> >>>> just load it on demand then once we fault? This code path really\n"
@@ -29,23 +29,23 @@
  "> >>>\n"
  "> >>> No we can't, read 6/6.\n"
  "> >>\n"
- "> >> So we have to make sure we're completely unlazy when it comes to a  \n"
+ "> >> So we have to make sure we're completely unlazy when it comes to a =20\n"
  "> KVM\n"
  "> >> guest. Are we?\n"
  "> >\n"
  "> > Yes, because MSR[SPV] is under its control.\n"
- "> \n"
- "> Oh, sure, KVM wants it unlazy. That part is obvious. But does the  \n"
- "> kernel always give us unlazyness? The way I read the code, process.c  \n"
+ ">=20\n"
+ "> Oh, sure, KVM wants it unlazy. That part is obvious. But does the =20\n"
+ "> kernel always give us unlazyness? The way I read the code, process.c =20\n"
  "> goes lazy when !CONFIG_SMP.\n"
- "> \n"
- "> So the big question is why we're manually enforcing FPU giveup, but  \n"
+ ">=20\n"
+ "> So the big question is why we're manually enforcing FPU giveup, but =20\n"
  "> not Altivec giveup? One of the 2 probably is wrong :).\n"
  "\n"
- "Why do you think we're not enforcing it for Altivec?  Is there some  \n"
- "specific piece of code you're referring to that is different in this  \n"
+ "Why do you think we're not enforcing it for Altivec?  Is there some =20\n"
+ "specific piece of code you're referring to that is different in this =20\n"
  "regard?\n"
  "\n"
- -Scott
+ -Scott=
 
-36fe2a25cceace101f7cdd2ed00769fd0e7afb22d640a421f5f6bbd1ef840dd3
+df7086a7d2ffaf222c795204352bf3e43d7a964d9ed25953fd0dd117ba11a06b

diff --git a/a/content_digest b/N2/content_digest
index 6f0d7bf..b6260a1 100644
--- a/a/content_digest
+++ b/N2/content_digest
@@ -7,7 +7,7 @@
  "ref\0098F899F-54BF-4172-958B-C52C015F5142@suse.de\0"
  "From\0Scott Wood <scottwood@freescale.com>\0"
  "Subject\0Re: [PATCH 4/6] KVM: PPC: Book3E: Add AltiVec support\0"
- "Date\0Wed, 03 Jul 2013 18:36:15 +0000\0"
+ "Date\0Wed, 3 Jul 2013 13:36:15 -0500\0"
  "To\0Alexander Graf <agraf@suse.de>\0"
  "Cc\0Caraman Mihai Claudiu-B02008 <B02008@freescale.com>"
   kvm-ppc@vger.kernel.org <kvm-ppc@vger.kernel.org>
@@ -48,4 +48,4 @@
  "\n"
  -Scott
 
-36fe2a25cceace101f7cdd2ed00769fd0e7afb22d640a421f5f6bbd1ef840dd3
+4c5c4916fea3cf63ef7821991d115f9555c8fcf47450fc0254c612fe3aa6e26b

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.