All of lore.kernel.org
 help / color / mirror / Atom feed
diff for duplicates of <Y5fYcosbituc0kc4@google.com>

diff --git a/a/1.txt b/N1/1.txt
index 0c36e3e..eaec7be 100644
--- a/a/1.txt
+++ b/N1/1.txt
@@ -17,7 +17,7 @@ was purely to making as_id a generic 8-bit role.
 Ugh, it's even a very explicitly documented "feature".
 
   When compatible SMM space is enabled, SMM-mode CBO accesses to this range route
-  to physical system DRAM at 00_000A_0h ? 00_000B_FFFFh.
+  to physical system DRAM at 00_000A_0h – 00_000B_FFFFh.
   
   Non-SMM mode CBO accesses to this range are considered to be to the Video Buffer
   Area as described above. PCI Express* and DMI originated cycles to SMM space are not
@@ -26,7 +26,7 @@ Ugh, it's even a very explicitly documented "feature".
 I also forgot KVM supports SMBASE relocation :-(
 
 > In fact, KVM_MEM_X86_SMRAM was the first idea.  It was uglier than multiple
-> address spaces (https://lore.kernel.org/lkml/1431084034-8425-1-git-send-email-pbonzini at redhat.com).
+> address spaces (https://lore.kernel.org/lkml/1431084034-8425-1-git-send-email-pbonzini@redhat.com).
 > In retrospect there were probably ways to mix the best of the two designs,
 > but it wasn't generic enough.
 >
@@ -38,3 +38,7 @@ I also forgot KVM supports SMBASE relocation :-(
 > would be a natural hierarchy of levels.
 
 Ah, true.
+_______________________________________________
+kvmarm mailing list
+kvmarm@lists.cs.columbia.edu
+https://lists.cs.columbia.edu/mailman/listinfo/kvmarm
diff --git a/a/content_digest b/N1/content_digest
index a196feb..57c0ec1 100644
--- a/a/content_digest
+++ b/N1/content_digest
@@ -6,9 +6,42 @@
  "ref\0Y5dnWgJ0ine55/hN@google.com\0"
  "ref\001cb4882-7a06-176f-7d55-f80cca300ffd@redhat.com\0"
  "From\0Sean Christopherson <seanjc@google.com>\0"
- "Subject\0[RFC PATCH 01/37] KVM: x86/mmu: Store the address space ID directly in kvm_mmu_page_role\0"
+ "Subject\0Re: [RFC PATCH 01/37] KVM: x86/mmu: Store the address space ID directly in kvm_mmu_page_role\0"
  "Date\0Tue, 13 Dec 2022 01:42:10 +0000\0"
- "To\0kvm-riscv@lists.infradead.org\0"
+ "To\0Paolo Bonzini <pbonzini@redhat.com>\0"
+ "Cc\0Anshuman Khandual <anshuman.khandual@arm.com>"
+  Hugh Dickins <hughd@google.com>
+  Paul Walmsley <paul.walmsley@sifive.com>
+  Yang
+  Weijiang <weijiang.yang@intel.com>
+  Amit
+  Nadav <namit@vmware.com>
+  Colin Cross <ccross@google.com>
+  Ben Gardon <bgardon@google.com>
+  linux-riscv@lists.infradead.org <linux-riscv@lists.infradead.org>
+  kvmarm@lists.cs.columbia.edu <kvmarm@lists.cs.columbia.edu>
+  Yu Zhao <yuzhao@google.com>
+  Marc Zyngier <maz@kernel.org>
+  Huacai Chen <chenhuacai@kernel.org>
+ " Matthew Wilcox \\(Oracle\\) <willy@infradead.org>"
+  Aleksandar Markovic <aleksandar.qemu.devel@gmail.com>
+  Krish Sadhukhan <krish.sadhukhan@oracle.com>
+  Palmer Dabbelt <palmer@dabbelt.com>
+  Mingwei Zhang <mizhang@google.com>
+  Albert Ou <aou@eecs.berkeley.edu>
+  xu xin <cgel.zte@gmail.com>
+  Arnd Bergmann <arnd@arndb.de>
+  Liam R. Howlett <Liam.Howlett@oracle.com>
+  kvm@vger.kernel.org <kvm@vger.kernel.org>
+  Atish Patra <atishp@atishpatra.org>
+  David Matlack <dmatlack@google.com>
+  Suren Baghdasaryan <surenb@google.com>
+  Vlastimil Babka <vbabka@suse.cz>
+  linux-arm-kernel@lists.infradead.org <linux-arm-kernel@lists.infradead.org>
+  kvmarm@lists.linux.dev <kvmarm@lists.linux.dev>
+  linux-mips@vger.kernel.org <linux-mips@vger.kernel.org>
+  kvm-riscv@lists.infradead.org <kvm-riscv@lists.infradead.org>
+ " Andrew Morton <akpm@linux-foundation.org>\0"
  "\00:1\0"
  "b\0"
  "On Mon, Dec 12, 2022, Paolo Bonzini wrote:\n"
@@ -30,7 +63,7 @@
  "Ugh, it's even a very explicitly documented \"feature\".\n"
  "\n"
  "  When compatible SMM space is enabled, SMM-mode CBO accesses to this range route\n"
- "  to physical system DRAM at 00_000A_0h ? 00_000B_FFFFh.\n"
+ "  to physical system DRAM at 00_000A_0h \342\200\223 00_000B_FFFFh.\n"
  "  \n"
  "  Non-SMM mode CBO accesses to this range are considered to be to the Video Buffer\n"
  "  Area as described above. PCI Express* and DMI originated cycles to SMM space are not\n"
@@ -39,7 +72,7 @@
  "I also forgot KVM supports SMBASE relocation :-(\n"
  "\n"
  "> In fact, KVM_MEM_X86_SMRAM was the first idea.  It was uglier than multiple\n"
- "> address spaces (https://lore.kernel.org/lkml/1431084034-8425-1-git-send-email-pbonzini at redhat.com).\n"
+ "> address spaces (https://lore.kernel.org/lkml/1431084034-8425-1-git-send-email-pbonzini@redhat.com).\n"
  "> In retrospect there were probably ways to mix the best of the two designs,\n"
  "> but it wasn't generic enough.\n"
  ">\n"
@@ -50,6 +83,10 @@
  "> Without a usecase that's hard to say.  It's just as possible that there\n"
  "> would be a natural hierarchy of levels.\n"
  "\n"
- Ah, true.
+ "Ah, true.\n"
+ "_______________________________________________\n"
+ "kvmarm mailing list\n"
+ "kvmarm@lists.cs.columbia.edu\n"
+ https://lists.cs.columbia.edu/mailman/listinfo/kvmarm
 
-a30559662e9507551c9c0d2bfba04a1545d3b6f94bd8cfbb4b29434a5e5059f0
+42f717ed56a90b1906b342daf886f287fd98fe89fc50719656317da61e89486e

diff --git a/a/1.txt b/N2/1.txt
index 0c36e3e..2b7dcea 100644
--- a/a/1.txt
+++ b/N2/1.txt
@@ -17,7 +17,7 @@ was purely to making as_id a generic 8-bit role.
 Ugh, it's even a very explicitly documented "feature".
 
   When compatible SMM space is enabled, SMM-mode CBO accesses to this range route
-  to physical system DRAM at 00_000A_0h ? 00_000B_FFFFh.
+  to physical system DRAM at 00_000A_0h – 00_000B_FFFFh.
   
   Non-SMM mode CBO accesses to this range are considered to be to the Video Buffer
   Area as described above. PCI Express* and DMI originated cycles to SMM space are not
@@ -26,7 +26,7 @@ Ugh, it's even a very explicitly documented "feature".
 I also forgot KVM supports SMBASE relocation :-(
 
 > In fact, KVM_MEM_X86_SMRAM was the first idea.  It was uglier than multiple
-> address spaces (https://lore.kernel.org/lkml/1431084034-8425-1-git-send-email-pbonzini at redhat.com).
+> address spaces (https://lore.kernel.org/lkml/1431084034-8425-1-git-send-email-pbonzini@redhat.com).
 > In retrospect there were probably ways to mix the best of the two designs,
 > but it wasn't generic enough.
 >
diff --git a/a/content_digest b/N2/content_digest
index a196feb..faa30de 100644
--- a/a/content_digest
+++ b/N2/content_digest
@@ -6,9 +6,50 @@
  "ref\0Y5dnWgJ0ine55/hN@google.com\0"
  "ref\001cb4882-7a06-176f-7d55-f80cca300ffd@redhat.com\0"
  "From\0Sean Christopherson <seanjc@google.com>\0"
- "Subject\0[RFC PATCH 01/37] KVM: x86/mmu: Store the address space ID directly in kvm_mmu_page_role\0"
+ "Subject\0Re: [RFC PATCH 01/37] KVM: x86/mmu: Store the address space ID directly in kvm_mmu_page_role\0"
  "Date\0Tue, 13 Dec 2022 01:42:10 +0000\0"
- "To\0kvm-riscv@lists.infradead.org\0"
+ "To\0Paolo Bonzini <pbonzini@redhat.com>\0"
+ "Cc\0David Matlack <dmatlack@google.com>"
+  Oliver Upton <oliver.upton@linux.dev>
+  Yang
+  Weijiang <weijiang.yang@intel.com>
+  Marc Zyngier <maz@kernel.org>
+  James Morse <james.morse@arm.com>
+  Alexandru Elisei <alexandru.elisei@arm.com>
+  Suzuki K Poulose <suzuki.poulose@arm.com>
+  Huacai Chen <chenhuacai@kernel.org>
+  Aleksandar Markovic <aleksandar.qemu.devel@gmail.com>
+  Anup Patel <anup@brainfault.org>
+  Atish Patra <atishp@atishpatra.org>
+  Paul Walmsley <paul.walmsley@sifive.com>
+  Palmer Dabbelt <palmer@dabbelt.com>
+  Albert Ou <aou@eecs.berkeley.edu>
+  Andrew Morton <akpm@linux-foundation.org>
+  Anshuman Khandual <anshuman.khandual@arm.com>
+  Amit
+  Nadav <namit@vmware.com>
+  Matthew Wilcox (Oracle) <willy@infradead.org>
+  Vlastimil Babka <vbabka@suse.cz>
+  Liam R. Howlett <Liam.Howlett@oracle.com>
+  Suren Baghdasaryan <surenb@google.com>
+  Peter Xu <peterx@redhat.com>
+  xu xin <cgel.zte@gmail.com>
+  Arnd Bergmann <arnd@arndb.de>
+  Yu Zhao <yuzhao@google.com>
+  Colin Cross <ccross@google.com>
+  Hugh Dickins <hughd@google.com>
+  Ben Gardon <bgardon@google.com>
+  Mingwei Zhang <mizhang@google.com>
+  Krish Sadhukhan <krish.sadhukhan@oracle.com>
+  Ricardo Koller <ricarkol@google.com>
+  Jing Zhang <jingzhangos@google.com>
+  linux-arm-kernel@lists.infradead.org <linux-arm-kernel@lists.infradead.org>
+  kvmarm@lists.linux.dev <kvmarm@lists.linux.dev>
+  kvmarm@lists.cs.columbia.edu <kvmarm@lists.cs.columbia.edu>
+  linux-mips@vger.kernel.org <linux-mips@vger.kernel.org>
+  kvm@vger.kernel.org <kvm@vger.kernel.org>
+  kvm-riscv@lists.infradead.org <kvm-riscv@lists.infradead.org>
+ " linux-riscv@lists.infradead.org <linux-riscv@lists.infradead.org>\0"
  "\00:1\0"
  "b\0"
  "On Mon, Dec 12, 2022, Paolo Bonzini wrote:\n"
@@ -30,7 +71,7 @@
  "Ugh, it's even a very explicitly documented \"feature\".\n"
  "\n"
  "  When compatible SMM space is enabled, SMM-mode CBO accesses to this range route\n"
- "  to physical system DRAM at 00_000A_0h ? 00_000B_FFFFh.\n"
+ "  to physical system DRAM at 00_000A_0h \342\200\223 00_000B_FFFFh.\n"
  "  \n"
  "  Non-SMM mode CBO accesses to this range are considered to be to the Video Buffer\n"
  "  Area as described above. PCI Express* and DMI originated cycles to SMM space are not\n"
@@ -39,7 +80,7 @@
  "I also forgot KVM supports SMBASE relocation :-(\n"
  "\n"
  "> In fact, KVM_MEM_X86_SMRAM was the first idea.  It was uglier than multiple\n"
- "> address spaces (https://lore.kernel.org/lkml/1431084034-8425-1-git-send-email-pbonzini at redhat.com).\n"
+ "> address spaces (https://lore.kernel.org/lkml/1431084034-8425-1-git-send-email-pbonzini@redhat.com).\n"
  "> In retrospect there were probably ways to mix the best of the two designs,\n"
  "> but it wasn't generic enough.\n"
  ">\n"
@@ -52,4 +93,4 @@
  "\n"
  Ah, true.
 
-a30559662e9507551c9c0d2bfba04a1545d3b6f94bd8cfbb4b29434a5e5059f0
+01ba447e8e53c1941bb8f998bf57747f49dd2ef22ff9936255b0559bdc1975e5

diff --git a/a/1.txt b/N3/1.txt
index 0c36e3e..432f10a 100644
--- a/a/1.txt
+++ b/N3/1.txt
@@ -17,7 +17,7 @@ was purely to making as_id a generic 8-bit role.
 Ugh, it's even a very explicitly documented "feature".
 
   When compatible SMM space is enabled, SMM-mode CBO accesses to this range route
-  to physical system DRAM at 00_000A_0h ? 00_000B_FFFFh.
+  to physical system DRAM at 00_000A_0h – 00_000B_FFFFh.
   
   Non-SMM mode CBO accesses to this range are considered to be to the Video Buffer
   Area as described above. PCI Express* and DMI originated cycles to SMM space are not
@@ -26,7 +26,7 @@ Ugh, it's even a very explicitly documented "feature".
 I also forgot KVM supports SMBASE relocation :-(
 
 > In fact, KVM_MEM_X86_SMRAM was the first idea.  It was uglier than multiple
-> address spaces (https://lore.kernel.org/lkml/1431084034-8425-1-git-send-email-pbonzini at redhat.com).
+> address spaces (https://lore.kernel.org/lkml/1431084034-8425-1-git-send-email-pbonzini@redhat.com).
 > In retrospect there were probably ways to mix the best of the two designs,
 > but it wasn't generic enough.
 >
@@ -38,3 +38,8 @@ I also forgot KVM supports SMBASE relocation :-(
 > would be a natural hierarchy of levels.
 
 Ah, true.
+
+_______________________________________________
+linux-riscv mailing list
+linux-riscv@lists.infradead.org
+http://lists.infradead.org/mailman/listinfo/linux-riscv
diff --git a/a/content_digest b/N3/content_digest
index a196feb..f833625 100644
--- a/a/content_digest
+++ b/N3/content_digest
@@ -6,9 +6,50 @@
  "ref\0Y5dnWgJ0ine55/hN@google.com\0"
  "ref\001cb4882-7a06-176f-7d55-f80cca300ffd@redhat.com\0"
  "From\0Sean Christopherson <seanjc@google.com>\0"
- "Subject\0[RFC PATCH 01/37] KVM: x86/mmu: Store the address space ID directly in kvm_mmu_page_role\0"
+ "Subject\0Re: [RFC PATCH 01/37] KVM: x86/mmu: Store the address space ID directly in kvm_mmu_page_role\0"
  "Date\0Tue, 13 Dec 2022 01:42:10 +0000\0"
- "To\0kvm-riscv@lists.infradead.org\0"
+ "To\0Paolo Bonzini <pbonzini@redhat.com>\0"
+ "Cc\0David Matlack <dmatlack@google.com>"
+  Oliver Upton <oliver.upton@linux.dev>
+  Yang
+  Weijiang <weijiang.yang@intel.com>
+  Marc Zyngier <maz@kernel.org>
+  James Morse <james.morse@arm.com>
+  Alexandru Elisei <alexandru.elisei@arm.com>
+  Suzuki K Poulose <suzuki.poulose@arm.com>
+  Huacai Chen <chenhuacai@kernel.org>
+  Aleksandar Markovic <aleksandar.qemu.devel@gmail.com>
+  Anup Patel <anup@brainfault.org>
+  Atish Patra <atishp@atishpatra.org>
+  Paul Walmsley <paul.walmsley@sifive.com>
+  Palmer Dabbelt <palmer@dabbelt.com>
+  Albert Ou <aou@eecs.berkeley.edu>
+  Andrew Morton <akpm@linux-foundation.org>
+  Anshuman Khandual <anshuman.khandual@arm.com>
+  Amit
+  Nadav <namit@vmware.com>
+  Matthew Wilcox (Oracle) <willy@infradead.org>
+  Vlastimil Babka <vbabka@suse.cz>
+  Liam R. Howlett <Liam.Howlett@oracle.com>
+  Suren Baghdasaryan <surenb@google.com>
+  Peter Xu <peterx@redhat.com>
+  xu xin <cgel.zte@gmail.com>
+  Arnd Bergmann <arnd@arndb.de>
+  Yu Zhao <yuzhao@google.com>
+  Colin Cross <ccross@google.com>
+  Hugh Dickins <hughd@google.com>
+  Ben Gardon <bgardon@google.com>
+  Mingwei Zhang <mizhang@google.com>
+  Krish Sadhukhan <krish.sadhukhan@oracle.com>
+  Ricardo Koller <ricarkol@google.com>
+  Jing Zhang <jingzhangos@google.com>
+  linux-arm-kernel@lists.infradead.org <linux-arm-kernel@lists.infradead.org>
+  kvmarm@lists.linux.dev <kvmarm@lists.linux.dev>
+  kvmarm@lists.cs.columbia.edu <kvmarm@lists.cs.columbia.edu>
+  linux-mips@vger.kernel.org <linux-mips@vger.kernel.org>
+  kvm@vger.kernel.org <kvm@vger.kernel.org>
+  kvm-riscv@lists.infradead.org <kvm-riscv@lists.infradead.org>
+ " linux-riscv@lists.infradead.org <linux-riscv@lists.infradead.org>\0"
  "\00:1\0"
  "b\0"
  "On Mon, Dec 12, 2022, Paolo Bonzini wrote:\n"
@@ -30,7 +71,7 @@
  "Ugh, it's even a very explicitly documented \"feature\".\n"
  "\n"
  "  When compatible SMM space is enabled, SMM-mode CBO accesses to this range route\n"
- "  to physical system DRAM at 00_000A_0h ? 00_000B_FFFFh.\n"
+ "  to physical system DRAM at 00_000A_0h \342\200\223 00_000B_FFFFh.\n"
  "  \n"
  "  Non-SMM mode CBO accesses to this range are considered to be to the Video Buffer\n"
  "  Area as described above. PCI Express* and DMI originated cycles to SMM space are not\n"
@@ -39,7 +80,7 @@
  "I also forgot KVM supports SMBASE relocation :-(\n"
  "\n"
  "> In fact, KVM_MEM_X86_SMRAM was the first idea.  It was uglier than multiple\n"
- "> address spaces (https://lore.kernel.org/lkml/1431084034-8425-1-git-send-email-pbonzini at redhat.com).\n"
+ "> address spaces (https://lore.kernel.org/lkml/1431084034-8425-1-git-send-email-pbonzini@redhat.com).\n"
  "> In retrospect there were probably ways to mix the best of the two designs,\n"
  "> but it wasn't generic enough.\n"
  ">\n"
@@ -50,6 +91,11 @@
  "> Without a usecase that's hard to say.  It's just as possible that there\n"
  "> would be a natural hierarchy of levels.\n"
  "\n"
- Ah, true.
+ "Ah, true.\n"
+ "\n"
+ "_______________________________________________\n"
+ "linux-riscv mailing list\n"
+ "linux-riscv@lists.infradead.org\n"
+ http://lists.infradead.org/mailman/listinfo/linux-riscv
 
-a30559662e9507551c9c0d2bfba04a1545d3b6f94bd8cfbb4b29434a5e5059f0
+3b78a3d76d488ff437400620cf71b8111692430b2d9f3c34aaf023e1f12be0e6

diff --git a/a/1.txt b/N4/1.txt
index 0c36e3e..4f78990 100644
--- a/a/1.txt
+++ b/N4/1.txt
@@ -17,7 +17,7 @@ was purely to making as_id a generic 8-bit role.
 Ugh, it's even a very explicitly documented "feature".
 
   When compatible SMM space is enabled, SMM-mode CBO accesses to this range route
-  to physical system DRAM at 00_000A_0h ? 00_000B_FFFFh.
+  to physical system DRAM at 00_000A_0h – 00_000B_FFFFh.
   
   Non-SMM mode CBO accesses to this range are considered to be to the Video Buffer
   Area as described above. PCI Express* and DMI originated cycles to SMM space are not
@@ -26,7 +26,7 @@ Ugh, it's even a very explicitly documented "feature".
 I also forgot KVM supports SMBASE relocation :-(
 
 > In fact, KVM_MEM_X86_SMRAM was the first idea.  It was uglier than multiple
-> address spaces (https://lore.kernel.org/lkml/1431084034-8425-1-git-send-email-pbonzini at redhat.com).
+> address spaces (https://lore.kernel.org/lkml/1431084034-8425-1-git-send-email-pbonzini@redhat.com).
 > In retrospect there were probably ways to mix the best of the two designs,
 > but it wasn't generic enough.
 >
@@ -38,3 +38,8 @@ I also forgot KVM supports SMBASE relocation :-(
 > would be a natural hierarchy of levels.
 
 Ah, true.
+
+_______________________________________________
+linux-arm-kernel mailing list
+linux-arm-kernel@lists.infradead.org
+http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
diff --git a/a/content_digest b/N4/content_digest
index a196feb..0bc7dd5 100644
--- a/a/content_digest
+++ b/N4/content_digest
@@ -6,9 +6,50 @@
  "ref\0Y5dnWgJ0ine55/hN@google.com\0"
  "ref\001cb4882-7a06-176f-7d55-f80cca300ffd@redhat.com\0"
  "From\0Sean Christopherson <seanjc@google.com>\0"
- "Subject\0[RFC PATCH 01/37] KVM: x86/mmu: Store the address space ID directly in kvm_mmu_page_role\0"
+ "Subject\0Re: [RFC PATCH 01/37] KVM: x86/mmu: Store the address space ID directly in kvm_mmu_page_role\0"
  "Date\0Tue, 13 Dec 2022 01:42:10 +0000\0"
- "To\0kvm-riscv@lists.infradead.org\0"
+ "To\0Paolo Bonzini <pbonzini@redhat.com>\0"
+ "Cc\0David Matlack <dmatlack@google.com>"
+  Oliver Upton <oliver.upton@linux.dev>
+  Yang
+  Weijiang <weijiang.yang@intel.com>
+  Marc Zyngier <maz@kernel.org>
+  James Morse <james.morse@arm.com>
+  Alexandru Elisei <alexandru.elisei@arm.com>
+  Suzuki K Poulose <suzuki.poulose@arm.com>
+  Huacai Chen <chenhuacai@kernel.org>
+  Aleksandar Markovic <aleksandar.qemu.devel@gmail.com>
+  Anup Patel <anup@brainfault.org>
+  Atish Patra <atishp@atishpatra.org>
+  Paul Walmsley <paul.walmsley@sifive.com>
+  Palmer Dabbelt <palmer@dabbelt.com>
+  Albert Ou <aou@eecs.berkeley.edu>
+  Andrew Morton <akpm@linux-foundation.org>
+  Anshuman Khandual <anshuman.khandual@arm.com>
+  Amit
+  Nadav <namit@vmware.com>
+  Matthew Wilcox (Oracle) <willy@infradead.org>
+  Vlastimil Babka <vbabka@suse.cz>
+  Liam R. Howlett <Liam.Howlett@oracle.com>
+  Suren Baghdasaryan <surenb@google.com>
+  Peter Xu <peterx@redhat.com>
+  xu xin <cgel.zte@gmail.com>
+  Arnd Bergmann <arnd@arndb.de>
+  Yu Zhao <yuzhao@google.com>
+  Colin Cross <ccross@google.com>
+  Hugh Dickins <hughd@google.com>
+  Ben Gardon <bgardon@google.com>
+  Mingwei Zhang <mizhang@google.com>
+  Krish Sadhukhan <krish.sadhukhan@oracle.com>
+  Ricardo Koller <ricarkol@google.com>
+  Jing Zhang <jingzhangos@google.com>
+  linux-arm-kernel@lists.infradead.org <linux-arm-kernel@lists.infradead.org>
+  kvmarm@lists.linux.dev <kvmarm@lists.linux.dev>
+  kvmarm@lists.cs.columbia.edu <kvmarm@lists.cs.columbia.edu>
+  linux-mips@vger.kernel.org <linux-mips@vger.kernel.org>
+  kvm@vger.kernel.org <kvm@vger.kernel.org>
+  kvm-riscv@lists.infradead.org <kvm-riscv@lists.infradead.org>
+ " linux-riscv@lists.infradead.org <linux-riscv@lists.infradead.org>\0"
  "\00:1\0"
  "b\0"
  "On Mon, Dec 12, 2022, Paolo Bonzini wrote:\n"
@@ -30,7 +71,7 @@
  "Ugh, it's even a very explicitly documented \"feature\".\n"
  "\n"
  "  When compatible SMM space is enabled, SMM-mode CBO accesses to this range route\n"
- "  to physical system DRAM at 00_000A_0h ? 00_000B_FFFFh.\n"
+ "  to physical system DRAM at 00_000A_0h \342\200\223 00_000B_FFFFh.\n"
  "  \n"
  "  Non-SMM mode CBO accesses to this range are considered to be to the Video Buffer\n"
  "  Area as described above. PCI Express* and DMI originated cycles to SMM space are not\n"
@@ -39,7 +80,7 @@
  "I also forgot KVM supports SMBASE relocation :-(\n"
  "\n"
  "> In fact, KVM_MEM_X86_SMRAM was the first idea.  It was uglier than multiple\n"
- "> address spaces (https://lore.kernel.org/lkml/1431084034-8425-1-git-send-email-pbonzini at redhat.com).\n"
+ "> address spaces (https://lore.kernel.org/lkml/1431084034-8425-1-git-send-email-pbonzini@redhat.com).\n"
  "> In retrospect there were probably ways to mix the best of the two designs,\n"
  "> but it wasn't generic enough.\n"
  ">\n"
@@ -50,6 +91,11 @@
  "> Without a usecase that's hard to say.  It's just as possible that there\n"
  "> would be a natural hierarchy of levels.\n"
  "\n"
- Ah, true.
+ "Ah, true.\n"
+ "\n"
+ "_______________________________________________\n"
+ "linux-arm-kernel mailing list\n"
+ "linux-arm-kernel@lists.infradead.org\n"
+ http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
 
-a30559662e9507551c9c0d2bfba04a1545d3b6f94bd8cfbb4b29434a5e5059f0
+25ed38e1b9e7ac25b335590ba28b26e6b7f771fc40061f6b84332501210f428c

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.