diff for duplicates of <877dd9pfri.fsf@redhat.com>

diff --git a/a/1.txt b/N1/1.txt
index 3b46b6d..41fdc69 100644
--- a/a/1.txt
+++ b/N1/1.txt
@@ -3,18 +3,18 @@ Christian Borntraeger <borntraeger@de.ibm.com> writes:
 > Am 11.11.21 um 17:32 schrieb Paolo Bonzini:
 >> On 11/11/21 17:27, Vitaly Kuznetsov wrote:
 >>> This is a comtinuation of "KVM: x86: Drop arbitraty KVM_SOFT_MAX_VCPUS"
->>> (https://lore.kernel.org/kvm/20211111134733.86601-1-vkuznets at redhat.com/)
+>>> (https://lore.kernel.org/kvm/20211111134733.86601-1-vkuznets@redhat.com/)
 >>> work.
 >>>
 >>> 1) Enforce KVM_CAP_NR_VCPUS <= KVM_CAP_MAX_VCPUS rule on all
->>> ? architectures. [Sean Christopherson]
+>>>   architectures. [Sean Christopherson]
 >>> 2) Make KVM_CAP_NR_VCPUS return num_online_cpus() and not an arbitrary
->>> ? value of '710' on x86.
+>>>   value of '710' on x86.
 >>>
 >>> Everything but x86 was only 'eyeball tested', the change is trivial
 >>> but sorry in advance if I screwed up)
 >> 
->> Christian, can you look at this for s390?? Returning a fixed value seems wrong for KVM_CAP_NR_VCPUS.
+>> Christian, can you look at this for s390?  Returning a fixed value seems wrong for KVM_CAP_NR_VCPUS.
 >
 > If we talk about recommended number, then num_online_cpus() also seems to make sense on s390 so
 > if you change that for s390 as well I can ACK this.
@@ -59,7 +59,7 @@ index 6a6dd5e1daf6..1cfe36f6432e 100644
                 r = MACHINE_HAS_ESOP;
 
 For reference, see our ARM discussion:
-https://lore.kernel.org/kvm/20211111162746.100598-2-vkuznets at redhat.com/
+https://lore.kernel.org/kvm/20211111162746.100598-2-vkuznets@redhat.com/
 though 390's situation is different, the returned value for
 KVM_CAP_MAX_VCPUS is not VM-dependent.
 
diff --git a/a/content_digest b/N1/content_digest
index f98a343..b7f8d8e 100644
--- a/a/content_digest
+++ b/N1/content_digest
@@ -2,9 +2,27 @@
  "ref\04a3c7be7-12fa-6e47-64eb-02e6c5be5dbc@redhat.com\0"
  "ref\0ecd55383-7089-b3cd-30cc-3f9feb7eadb4@de.ibm.com\0"
  "From\0Vitaly Kuznetsov <vkuznets@redhat.com>\0"
- "Subject\0[PATCH 0/5] KVM: Cap KVM_CAP_NR_VCPUS by KVM_CAP_MAX_VCPUS and re-purpose it on x86\0"
- "Date\0Mon, 15 Nov 2021 17:04:01 +0100\0"
- "To\0kvm-riscv@lists.infradead.org\0"
+ "Subject\0Re: [PATCH 0/5] KVM: Cap KVM_CAP_NR_VCPUS by KVM_CAP_MAX_VCPUS and re-purpose it on x86\0"
+ "Date\0Mon, 15 Nov 2021 16:04:01 +0000\0"
+ "To\0Christian Borntraeger <borntraeger@de.ibm.com>"
+  Paolo Bonzini <pbonzini@redhat.com>
+ " kvm@vger.kernel.org\0"
+ "Cc\0Sean Christopherson <seanjc@google.com>"
+  Wanpeng Li <wanpengli@tencent.com>
+  Jim Mattson <jmattson@google.com>
+  Eduardo Habkost <ehabkost@redhat.com>
+  Marc Zyngier <maz@kernel.org>
+  Andrew Jones <drjones@redhat.com>
+  Huacai Chen <chenhuacai@kernel.org>
+  Aleksandar Markovic <aleksandar.qemu.devel@gmail.com>
+  Anup Patel <anup.patel@wdc.com>
+  Paul Mackerras <paulus@ozlabs.org>
+  Michael Ellerman <mpe@ellerman.id.au>
+  kvm-ppc@vger.kernel.org
+  linux-arm-kernel@lists.infradead.org
+  linux-mips@vger.kernel.org
+  kvm-riscv@lists.infradead.org
+ " linux-kernel@vger.kernel.org\0"
  "\00:1\0"
  "b\0"
  "Christian Borntraeger <borntraeger@de.ibm.com> writes:\n"
@@ -12,18 +30,18 @@
  "> Am 11.11.21 um 17:32 schrieb Paolo Bonzini:\n"
  ">> On 11/11/21 17:27, Vitaly Kuznetsov wrote:\n"
  ">>> This is a comtinuation of \"KVM: x86: Drop arbitraty KVM_SOFT_MAX_VCPUS\"\n"
- ">>> (https://lore.kernel.org/kvm/20211111134733.86601-1-vkuznets at redhat.com/)\n"
+ ">>> (https://lore.kernel.org/kvm/20211111134733.86601-1-vkuznets@redhat.com/)\n"
  ">>> work.\n"
  ">>>\n"
  ">>> 1) Enforce KVM_CAP_NR_VCPUS <= KVM_CAP_MAX_VCPUS rule on all\n"
- ">>> ? architectures. [Sean Christopherson]\n"
+ ">>> \302\240 architectures. [Sean Christopherson]\n"
  ">>> 2) Make KVM_CAP_NR_VCPUS return num_online_cpus() and not an arbitrary\n"
- ">>> ? value of '710' on x86.\n"
+ ">>> \302\240 value of '710' on x86.\n"
  ">>>\n"
  ">>> Everything but x86 was only 'eyeball tested', the change is trivial\n"
  ">>> but sorry in advance if I screwed up)\n"
  ">> \n"
- ">> Christian, can you look at this for s390?? Returning a fixed value seems wrong for KVM_CAP_NR_VCPUS.\n"
+ ">> Christian, can you look at this for s390?\302\240 Returning a fixed value seems wrong for KVM_CAP_NR_VCPUS.\n"
  ">\n"
  "> If we talk about recommended number, then num_online_cpus() also seems to make sense on s390 so\n"
  "> if you change that for s390 as well I can ACK this.\n"
@@ -68,11 +86,11 @@
  "                r = MACHINE_HAS_ESOP;\n"
  "\n"
  "For reference, see our ARM discussion:\n"
- "https://lore.kernel.org/kvm/20211111162746.100598-2-vkuznets at redhat.com/\n"
+ "https://lore.kernel.org/kvm/20211111162746.100598-2-vkuznets@redhat.com/\n"
  "though 390's situation is different, the returned value for\n"
  "KVM_CAP_MAX_VCPUS is not VM-dependent.\n"
  "\n"
  "-- \n"
  Vitaly
 
-d36d6a770a6e6c2e660b1927ca9c071c88665241c143bab21381ce01d4f0045e
+204836bf8a7c67ced1c7086b144c370604df07e340a201ad82587e2a57939fb2
