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

diff --git a/a/1.txt b/N1/1.txt
index e622743..ff73eb4 100644
--- a/a/1.txt
+++ b/N1/1.txt
@@ -1,39 +1,39 @@
 On 05/29/2013 06:57:32 PM, Benjamin Herrenschmidt wrote:
 > On Wed, 2013-05-29 at 18:38 -0500, Scott Wood wrote:
-> 
-> > > Yes. I'd like to have them in. Their implementation is actually  
+>=20
+> > > Yes. I'd like to have them in. Their implementation is actually =20
 > fairly
-> > > trivial and they cannot be emulated by qemu if the rest of the  
+> > > trivial and they cannot be emulated by qemu if the rest of the =20
 > XICS is
 > > > in the kernel, so it's a problem.
 > >
-> > OK.  Does it make more sense for you to take it as Paul suggested,  
+> > OK.  Does it make more sense for you to take it as Paul suggested, =20
 > or
 > > for Gleb or Marcelo to pick it up directly?
-> 
+>=20
 > I'll take it.
 
 Acked-by: Scott Wood <scottwood@freescale.com>
 
-> > Then rm_action should always be 0 for these hcalls, right?  So  
+> > Then rm_action should always be 0 for these hcalls, right?  So =20
 > there's
 > > no correctness reason to keep the hcalls in separate switch
-> > statements.  You shave off a few cycles checking rm_action, at the  
+> > statements.  You shave off a few cycles checking rm_action, at the =20
 > cost
 > > of needing to change kvmppc_xics_hcall() if a real-mode version of
 > > these hcalls is ever done.
-> 
-> No, because rm_action will also be 0 if the hcall was fully done in  
+>=20
+> No, because rm_action will also be 0 if the hcall was fully done in =20
 > real
-> mode (which can happen, that's our fast path), in which case we do  
+> mode (which can happen, that's our fast path), in which case we do =20
 > *NOT*
 > want to to be re-done in virtual mode.
-> 
-> That's why we always return whether rm_action is 0 or not when  
+>=20
+> That's why we always return whether rm_action is 0 or not when =20
 > real-mode
 > is enabled.
 
-Oh, I misread the code and thought the decision to return was based on  
+Oh, I misread the code and thought the decision to return was based on =20
 the return value of kvmppc_xics_rm_complete.  Sorry about that. :-(
 
--Scott
+-Scott=
diff --git a/a/content_digest b/N1/content_digest
index 30bc661..b7391b0 100644
--- a/a/content_digest
+++ b/N1/content_digest
@@ -2,55 +2,55 @@
  "ref\01369871852.3928.79.camel@pasglop\0"
  "From\0Scott Wood <scottwood@freescale.com>\0"
  "Subject\0Re: [PATCH] KVM: PPC: Book3S: Add support for H_IPOLL and H_XIRR_X in XICS emulation\0"
- "Date\0Thu, 30 May 2013 00:07:13 +0000\0"
+ "Date\0Wed, 29 May 2013 19:07:13 -0500\0"
  "To\0Benjamin Herrenschmidt <benh@kernel.crashing.org>\0"
- "Cc\0Paul Mackerras <paulus@samba.org>"
+ "Cc\0kvm@vger.kernel.org"
+  Gleb Natapov <gleb@redhat.com>
+  Marcelo Tosatti <mtosatti@redhat.com>
+  Alexander Graf <agraf@suse.de>
   kvm-ppc@vger.kernel.org
-  kvm@vger.kernel.org
   linuxppc-dev@ozlabs.org
-  Alexander Graf <agraf@suse.de>
-  Gleb Natapov <gleb@redhat.com>
- " Marcelo Tosatti <mtosatti@redhat.com>\0"
+ " Paul Mackerras <paulus@samba.org>\0"
  "\00:1\0"
  "b\0"
  "On 05/29/2013 06:57:32 PM, Benjamin Herrenschmidt wrote:\n"
  "> On Wed, 2013-05-29 at 18:38 -0500, Scott Wood wrote:\n"
- "> \n"
- "> > > Yes. I'd like to have them in. Their implementation is actually  \n"
+ ">=20\n"
+ "> > > Yes. I'd like to have them in. Their implementation is actually =20\n"
  "> fairly\n"
- "> > > trivial and they cannot be emulated by qemu if the rest of the  \n"
+ "> > > trivial and they cannot be emulated by qemu if the rest of the =20\n"
  "> XICS is\n"
  "> > > in the kernel, so it's a problem.\n"
  "> >\n"
- "> > OK.  Does it make more sense for you to take it as Paul suggested,  \n"
+ "> > OK.  Does it make more sense for you to take it as Paul suggested, =20\n"
  "> or\n"
  "> > for Gleb or Marcelo to pick it up directly?\n"
- "> \n"
+ ">=20\n"
  "> I'll take it.\n"
  "\n"
  "Acked-by: Scott Wood <scottwood@freescale.com>\n"
  "\n"
- "> > Then rm_action should always be 0 for these hcalls, right?  So  \n"
+ "> > Then rm_action should always be 0 for these hcalls, right?  So =20\n"
  "> there's\n"
  "> > no correctness reason to keep the hcalls in separate switch\n"
- "> > statements.  You shave off a few cycles checking rm_action, at the  \n"
+ "> > statements.  You shave off a few cycles checking rm_action, at the =20\n"
  "> cost\n"
  "> > of needing to change kvmppc_xics_hcall() if a real-mode version of\n"
  "> > these hcalls is ever done.\n"
- "> \n"
- "> No, because rm_action will also be 0 if the hcall was fully done in  \n"
+ ">=20\n"
+ "> No, because rm_action will also be 0 if the hcall was fully done in =20\n"
  "> real\n"
- "> mode (which can happen, that's our fast path), in which case we do  \n"
+ "> mode (which can happen, that's our fast path), in which case we do =20\n"
  "> *NOT*\n"
  "> want to to be re-done in virtual mode.\n"
- "> \n"
- "> That's why we always return whether rm_action is 0 or not when  \n"
+ ">=20\n"
+ "> That's why we always return whether rm_action is 0 or not when =20\n"
  "> real-mode\n"
  "> is enabled.\n"
  "\n"
- "Oh, I misread the code and thought the decision to return was based on  \n"
+ "Oh, I misread the code and thought the decision to return was based on =20\n"
  "the return value of kvmppc_xics_rm_complete.  Sorry about that. :-(\n"
  "\n"
- -Scott
+ -Scott=
 
-7b0d83ad29bbcd42123d2021a00fbd2b7e28d5b2472a0d59f4bf913d3aef65cd
+9026ade6586f9a884f0be192fa7b92537bcc0879c9d236e666a3ee2a9965e02a

diff --git a/a/content_digest b/N2/content_digest
index 30bc661..15d6c7b 100644
--- a/a/content_digest
+++ b/N2/content_digest
@@ -2,12 +2,12 @@
  "ref\01369871852.3928.79.camel@pasglop\0"
  "From\0Scott Wood <scottwood@freescale.com>\0"
  "Subject\0Re: [PATCH] KVM: PPC: Book3S: Add support for H_IPOLL and H_XIRR_X in XICS emulation\0"
- "Date\0Thu, 30 May 2013 00:07:13 +0000\0"
+ "Date\0Wed, 29 May 2013 19:07:13 -0500\0"
  "To\0Benjamin Herrenschmidt <benh@kernel.crashing.org>\0"
  "Cc\0Paul Mackerras <paulus@samba.org>"
-  kvm-ppc@vger.kernel.org
-  kvm@vger.kernel.org
-  linuxppc-dev@ozlabs.org
+  <kvm-ppc@vger.kernel.org>
+  <kvm@vger.kernel.org>
+  <linuxppc-dev@ozlabs.org>
   Alexander Graf <agraf@suse.de>
   Gleb Natapov <gleb@redhat.com>
  " Marcelo Tosatti <mtosatti@redhat.com>\0"
@@ -53,4 +53,4 @@
  "\n"
  -Scott
 
-7b0d83ad29bbcd42123d2021a00fbd2b7e28d5b2472a0d59f4bf913d3aef65cd
+96b7c4a83f39eae0979815deeaaa6a0f036499615134b8915c701d49cba5e8f6

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.