diff for duplicates of <300B73AA675FCE4A93EB4FC1D42459FF20D198@039-SN2MPN1-012.039d.mgd.msft.net>

diff --git a/a/1.txt b/N1/1.txt
index 565072e..044efc3 100644
--- a/a/1.txt
+++ b/N1/1.txt
@@ -6,10 +6,10 @@
 > dev@lists.ozlabs.org; qemu-ppc@nongnu.org
 > Subject: Re: [Qemu-ppc] [RFC PATCH 05/17] KVM: PPC: booke: Extend MAS2
 > EPN mask for 64-bit
-> 
-> 
+>=20
+>=20
 > On 05.07.2012, at 13:14, Caraman Mihai Claudiu-B02008 wrote:
-> 
+>=20
 > >
 > >
 > >> -----Original Message-----
@@ -31,7 +31,8 @@
 > >> Please see section 6.11.4.8 in the PowerISA 2.06b:
 > >>
 > >> MMU behavior is largely unaffected by whether the thread is in 32-bit
-> >> computation mode (MSRCM=0) or 64- bit computation mode (MSRCM=1). The
+> >> computation mode (MSRCM=3D0) or 64- bit computation mode (MSRCM=3D1). =
+The
 > >> only differ- ences occur in the EPN field of the TLB entry and the EPN
 > >> field of MAS2. The differences are summarized here.
 > >>
@@ -46,21 +47,23 @@
 > which
 > >> can happen regardless of CONFIG_64BIT.
 > >
-> > MAS2_EPN reflects EPN field of MAS2 aka bits 0:51 (for MAV = 1.0)
+> > MAS2_EPN reflects EPN field of MAS2 aka bits 0:51 (for MAV =3D 1.0)
 > according
 > > to section 6.10.3.10 in the PowerISA 2.06b.
 > >
 > > MAS2_EPN is not used in tlbwe execution emulation, we have MAS2_VAL
 > define
 > > for this case.
-> 
-> So tlbe->mas2 is guaranteed to have the upper bits be 0 when MSR.CM=0?
+>=20
+> So tlbe->mas2 is guaranteed to have the upper bits be 0 when MSR.CM=3D0?
 
 We chose to mask out mas2 upper bits on tlbwe emulation so gtlbe->mas2 will
-respect this but vcpu->arch.shared->mas2 will not. tlb entry selection does not
-require this treatment since EPN upper bits are not taken into consideration anyway.
+respect this but vcpu->arch.shared->mas2 will not. tlb entry selection does=
+ not
+require this treatment since EPN upper bits are not taken into consideratio=
+n anyway.
 
-> 
+>=20
 > >
 > >> Also, we need to implement MAS2U, to potentially make the upper 32bits
 > of
@@ -68,16 +71,16 @@ require this treatment since EPN upper bits are not taken into consideration any
 > bit.
 > >
 > > MAS2U is guest privileged why does it need special care?
-> 
+>=20
 > Maybe it's mapped to the upper bits of GMAS2 automatically?
 
 GMAS2?
 
-> 
+>=20
 > > Freescale core Manuals and EREF does not mention MAS2U so I think I our
 > case
 > > it is not implemented.
-> 
+>=20
 > Please check with a simple mfspr() test on real hw to see if it really
 > isn't implemented.
 
diff --git a/a/content_digest b/N1/content_digest
index b4c5650..27ed3a7 100644
--- a/a/content_digest
+++ b/N1/content_digest
@@ -26,10 +26,10 @@
   "To\0Alexander Graf <agraf\@suse.de>\0"
 ]
 [
-  "Cc\0kvm-ppc\@vger.kernel.org <kvm-ppc\@vger.kernel.org>",
-  " kvm\@vger.kernel.org <kvm\@vger.kernel.org>",
+  "Cc\0qemu-ppc\@nongnu.org <qemu-ppc\@nongnu.org>",
   " linuxppc-dev\@lists.ozlabs.org <linuxppc-dev\@lists.ozlabs.org>",
-  " qemu-ppc\@nongnu.org <qemu-ppc\@nongnu.org>\0"
+  " kvm\@vger.kernel.org <kvm\@vger.kernel.org>",
+  " kvm-ppc\@vger.kernel.org <kvm-ppc\@vger.kernel.org>\0"
 ]
 [
   "\0000:1\0"
@@ -46,10 +46,10 @@
   "> dev\@lists.ozlabs.org; qemu-ppc\@nongnu.org\n",
   "> Subject: Re: [Qemu-ppc] [RFC PATCH 05/17] KVM: PPC: booke: Extend MAS2\n",
   "> EPN mask for 64-bit\n",
-  "> \n",
-  "> \n",
+  ">=20\n",
+  ">=20\n",
   "> On 05.07.2012, at 13:14, Caraman Mihai Claudiu-B02008 wrote:\n",
-  "> \n",
+  ">=20\n",
   "> >\n",
   "> >\n",
   "> >> -----Original Message-----\n",
@@ -71,7 +71,8 @@
   "> >> Please see section 6.11.4.8 in the PowerISA 2.06b:\n",
   "> >>\n",
   "> >> MMU behavior is largely unaffected by whether the thread is in 32-bit\n",
-  "> >> computation mode (MSRCM=0) or 64- bit computation mode (MSRCM=1). The\n",
+  "> >> computation mode (MSRCM=3D0) or 64- bit computation mode (MSRCM=3D1). =\n",
+  "The\n",
   "> >> only differ- ences occur in the EPN field of the TLB entry and the EPN\n",
   "> >> field of MAS2. The differences are summarized here.\n",
   "> >>\n",
@@ -86,21 +87,23 @@
   "> which\n",
   "> >> can happen regardless of CONFIG_64BIT.\n",
   "> >\n",
-  "> > MAS2_EPN reflects EPN field of MAS2 aka bits 0:51 (for MAV = 1.0)\n",
+  "> > MAS2_EPN reflects EPN field of MAS2 aka bits 0:51 (for MAV =3D 1.0)\n",
   "> according\n",
   "> > to section 6.10.3.10 in the PowerISA 2.06b.\n",
   "> >\n",
   "> > MAS2_EPN is not used in tlbwe execution emulation, we have MAS2_VAL\n",
   "> define\n",
   "> > for this case.\n",
-  "> \n",
-  "> So tlbe->mas2 is guaranteed to have the upper bits be 0 when MSR.CM=0?\n",
+  ">=20\n",
+  "> So tlbe->mas2 is guaranteed to have the upper bits be 0 when MSR.CM=3D0?\n",
   "\n",
   "We chose to mask out mas2 upper bits on tlbwe emulation so gtlbe->mas2 will\n",
-  "respect this but vcpu->arch.shared->mas2 will not. tlb entry selection does not\n",
-  "require this treatment since EPN upper bits are not taken into consideration anyway.\n",
+  "respect this but vcpu->arch.shared->mas2 will not. tlb entry selection does=\n",
+  " not\n",
+  "require this treatment since EPN upper bits are not taken into consideratio=\n",
+  "n anyway.\n",
   "\n",
-  "> \n",
+  ">=20\n",
   "> >\n",
   "> >> Also, we need to implement MAS2U, to potentially make the upper 32bits\n",
   "> of\n",
@@ -108,16 +111,16 @@
   "> bit.\n",
   "> >\n",
   "> > MAS2U is guest privileged why does it need special care?\n",
-  "> \n",
+  ">=20\n",
   "> Maybe it's mapped to the upper bits of GMAS2 automatically?\n",
   "\n",
   "GMAS2?\n",
   "\n",
-  "> \n",
+  ">=20\n",
   "> > Freescale core Manuals and EREF does not mention MAS2U so I think I our\n",
   "> case\n",
   "> > it is not implemented.\n",
-  "> \n",
+  ">=20\n",
   "> Please check with a simple mfspr() test on real hw to see if it really\n",
   "> isn't implemented.\n",
   "\n",
@@ -126,4 +129,4 @@
   "-Mike"
 ]
 
-0c3629c81cc88e47990e17a467cb140b482395e8de7b30e9998850ca3db6cba2
+16aba963952b49d2563ca1e71e71b7b2f54f923fb050dd84b2fe88d9996e0f70
