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

diff --git a/a/1.txt b/N1/1.txt
index 6590031..4684799 100644
--- a/a/1.txt
+++ b/N1/1.txt
@@ -1,9 +1,9 @@
 On Thu, Nov 02, 2023, Fuad Tabba wrote:
-> On Wed, Nov 1, 2023 at 9:55?PM Sean Christopherson <seanjc@google.com> wrote:
+> On Wed, Nov 1, 2023 at 9:55 PM Sean Christopherson <seanjc@google.com> wrote:
 > > E.g. a misbehaving userspace could prematurely delete a memslot.  And the more
 > > fun example is intrahost migration, where the plan is to allow pointing multiple
 > > guest_memfd files at a single guest_memfd inode:
-> > https://lore.kernel.org/all/cover.1691446946.git.ackerleytng at google.com
+> > https://lore.kernel.org/all/cover.1691446946.git.ackerleytng@google.com
 > >
 > > There was a lot of discussion for this, but it's scattered all over the place.
 > > The TL;DR is is that the inode will represent physical memory, and a file will
@@ -11,11 +11,11 @@ On Thu, Nov 02, 2023, Fuad Tabba wrote:
 > > isn't reclaimed until the inode is truncated/punched.
 > >
 > > I _think_ this reflects the most recent plan from the guest_memfd side:
-> > https://lore.kernel.org/all/1233d749211c08d51f9ca5d427938d47f008af1f.1689893403.git.isaku.yamahata at intel.com
+> > https://lore.kernel.org/all/1233d749211c08d51f9ca5d427938d47f008af1f.1689893403.git.isaku.yamahata@intel.com
 
 Doh, sitting in my TODO folder...
 
-https://lore.kernel.org/all/20231016115028.996656-1-michael.roth at amd.com
+https://lore.kernel.org/all/20231016115028.996656-1-michael.roth@amd.com
 
 > Thanks for pointing that out. I think this might be the way to go.
 > I'll have a closer look at this and see how to get it to work with
diff --git a/a/content_digest b/N1/content_digest
index 9658dd5..b662ece 100644
--- a/a/content_digest
+++ b/N1/content_digest
@@ -6,17 +6,60 @@
  "ref\0ZULJYg5cf1UrNq3e@google.com\0"
  "ref\0CA+EHjTzGzXnfXHh0m5iHt9m3BxerkUS56EVPDA_az6n2FRnk3w@mail.gmail.com\0"
  "From\0Sean Christopherson <seanjc@google.com>\0"
- "Subject\0[PATCH v13 16/35] KVM: Add KVM_CREATE_GUEST_MEMFD ioctl() for guest-specific backing memory\0"
+ "Subject\0Re: [PATCH v13 16/35] KVM: Add KVM_CREATE_GUEST_MEMFD ioctl() for guest-specific backing memory\0"
  "Date\0Fri, 3 Nov 2023 16:17:23 -0700\0"
- "To\0kvm-riscv@lists.infradead.org\0"
+ "To\0Fuad Tabba <tabba@google.com>\0"
+ "Cc\0Paolo Bonzini <pbonzini@redhat.com>"
+  Marc Zyngier <maz@kernel.org>
+  Oliver Upton <oliver.upton@linux.dev>
+  Huacai Chen <chenhuacai@kernel.org>
+  Michael Ellerman <mpe@ellerman.id.au>
+  Anup Patel <anup@brainfault.org>
+  Paul Walmsley <paul.walmsley@sifive.com>
+  Palmer Dabbelt <palmer@dabbelt.com>
+  Albert Ou <aou@eecs.berkeley.edu>
+  Alexander Viro <viro@zeniv.linux.org.uk>
+  Christian Brauner <brauner@kernel.org>
+  Matthew Wilcox (Oracle) <willy@infradead.org>
+  Andrew Morton <akpm@linux-foundation.org>
+  kvm@vger.kernel.org
+  linux-arm-kernel@lists.infradead.org
+  kvmarm@lists.linux.dev
+  linux-mips@vger.kernel.org
+  linuxppc-dev@lists.ozlabs.org
+  kvm-riscv@lists.infradead.org
+  linux-riscv@lists.infradead.org
+  linux-fsdevel@vger.kernel.org
+  linux-mm@kvack.org
+  linux-kernel@vger.kernel.org
+  Xiaoyao Li <xiaoyao.li@intel.com>
+  Xu Yilun <yilun.xu@intel.com>
+  Chao Peng <chao.p.peng@linux.intel.com>
+  Jarkko Sakkinen <jarkko@kernel.org>
+  Anish Moorthy <amoorthy@google.com>
+  David Matlack <dmatlack@google.com>
+  Yu Zhang <yu.c.zhang@linux.intel.com>
+  Isaku Yamahata <isaku.yamahata@intel.com>
+ " Micka\303\253l Sala\303\274n <mic@digikod.net>"
+  Vlastimil Babka <vbabka@suse.cz>
+  Vishal Annapurve <vannapurve@google.com>
+  Ackerley Tng <ackerleytng@google.com>
+  Maciej Szmigiero <mail@maciej.szmigiero.name>
+  David Hildenbrand <david@redhat.com>
+  Quentin Perret <qperret@google.com>
+  Michael Roth <michael.roth@amd.com>
+  Wang <wei.w.wang@intel.com>
+  Liam Merwick <liam.merwick@oracle.com>
+  Isaku Yamahata <isaku.yamahata@gmail.com>
+ " Kirill A . Shutemov <kirill.shutemov@linux.intel.com>\0"
  "\00:1\0"
  "b\0"
  "On Thu, Nov 02, 2023, Fuad Tabba wrote:\n"
- "> On Wed, Nov 1, 2023 at 9:55?PM Sean Christopherson <seanjc@google.com> wrote:\n"
+ "> On Wed, Nov 1, 2023 at 9:55\342\200\257PM Sean Christopherson <seanjc@google.com> wrote:\n"
  "> > E.g. a misbehaving userspace could prematurely delete a memslot.  And the more\n"
  "> > fun example is intrahost migration, where the plan is to allow pointing multiple\n"
  "> > guest_memfd files at a single guest_memfd inode:\n"
- "> > https://lore.kernel.org/all/cover.1691446946.git.ackerleytng at google.com\n"
+ "> > https://lore.kernel.org/all/cover.1691446946.git.ackerleytng@google.com\n"
  "> >\n"
  "> > There was a lot of discussion for this, but it's scattered all over the place.\n"
  "> > The TL;DR is is that the inode will represent physical memory, and a file will\n"
@@ -24,14 +67,14 @@
  "> > isn't reclaimed until the inode is truncated/punched.\n"
  "> >\n"
  "> > I _think_ this reflects the most recent plan from the guest_memfd side:\n"
- "> > https://lore.kernel.org/all/1233d749211c08d51f9ca5d427938d47f008af1f.1689893403.git.isaku.yamahata at intel.com\n"
+ "> > https://lore.kernel.org/all/1233d749211c08d51f9ca5d427938d47f008af1f.1689893403.git.isaku.yamahata@intel.com\n"
  "\n"
  "Doh, sitting in my TODO folder...\n"
  "\n"
- "https://lore.kernel.org/all/20231016115028.996656-1-michael.roth at amd.com\n"
+ "https://lore.kernel.org/all/20231016115028.996656-1-michael.roth@amd.com\n"
  "\n"
  "> Thanks for pointing that out. I think this might be the way to go.\n"
  "> I'll have a closer look at this and see how to get it to work with\n"
  > pKVM.
 
-110ef2b4bc84174267e26f60fc95060e0cec67199b3d5e0a1ddab4401033dff4
+e90570cf31da4c94015da7a3feac888087d83805b44fd3c032f77cdc10110bfd

diff --git a/a/1.txt b/N2/1.txt
index 6590031..39b397a 100644
--- a/a/1.txt
+++ b/N2/1.txt
@@ -1,9 +1,9 @@
 On Thu, Nov 02, 2023, Fuad Tabba wrote:
-> On Wed, Nov 1, 2023 at 9:55?PM Sean Christopherson <seanjc@google.com> wrote:
+> On Wed, Nov 1, 2023 at 9:55 PM Sean Christopherson <seanjc@google.com> wrote:
 > > E.g. a misbehaving userspace could prematurely delete a memslot.  And the more
 > > fun example is intrahost migration, where the plan is to allow pointing multiple
 > > guest_memfd files at a single guest_memfd inode:
-> > https://lore.kernel.org/all/cover.1691446946.git.ackerleytng at google.com
+> > https://lore.kernel.org/all/cover.1691446946.git.ackerleytng@google.com
 > >
 > > There was a lot of discussion for this, but it's scattered all over the place.
 > > The TL;DR is is that the inode will represent physical memory, and a file will
@@ -11,12 +11,17 @@ On Thu, Nov 02, 2023, Fuad Tabba wrote:
 > > isn't reclaimed until the inode is truncated/punched.
 > >
 > > I _think_ this reflects the most recent plan from the guest_memfd side:
-> > https://lore.kernel.org/all/1233d749211c08d51f9ca5d427938d47f008af1f.1689893403.git.isaku.yamahata at intel.com
+> > https://lore.kernel.org/all/1233d749211c08d51f9ca5d427938d47f008af1f.1689893403.git.isaku.yamahata@intel.com
 
 Doh, sitting in my TODO folder...
 
-https://lore.kernel.org/all/20231016115028.996656-1-michael.roth at amd.com
+https://lore.kernel.org/all/20231016115028.996656-1-michael.roth@amd.com
 
 > Thanks for pointing that out. I think this might be the way to go.
 > I'll have a closer look at this and see how to get it to work with
 > pKVM.
+
+_______________________________________________
+linux-riscv mailing list
+linux-riscv@lists.infradead.org
+http://lists.infradead.org/mailman/listinfo/linux-riscv
diff --git a/a/content_digest b/N2/content_digest
index 9658dd5..45ee1c5 100644
--- a/a/content_digest
+++ b/N2/content_digest
@@ -6,17 +6,60 @@
  "ref\0ZULJYg5cf1UrNq3e@google.com\0"
  "ref\0CA+EHjTzGzXnfXHh0m5iHt9m3BxerkUS56EVPDA_az6n2FRnk3w@mail.gmail.com\0"
  "From\0Sean Christopherson <seanjc@google.com>\0"
- "Subject\0[PATCH v13 16/35] KVM: Add KVM_CREATE_GUEST_MEMFD ioctl() for guest-specific backing memory\0"
+ "Subject\0Re: [PATCH v13 16/35] KVM: Add KVM_CREATE_GUEST_MEMFD ioctl() for guest-specific backing memory\0"
  "Date\0Fri, 3 Nov 2023 16:17:23 -0700\0"
- "To\0kvm-riscv@lists.infradead.org\0"
+ "To\0Fuad Tabba <tabba@google.com>\0"
+ "Cc\0Paolo Bonzini <pbonzini@redhat.com>"
+  Marc Zyngier <maz@kernel.org>
+  Oliver Upton <oliver.upton@linux.dev>
+  Huacai Chen <chenhuacai@kernel.org>
+  Michael Ellerman <mpe@ellerman.id.au>
+  Anup Patel <anup@brainfault.org>
+  Paul Walmsley <paul.walmsley@sifive.com>
+  Palmer Dabbelt <palmer@dabbelt.com>
+  Albert Ou <aou@eecs.berkeley.edu>
+  Alexander Viro <viro@zeniv.linux.org.uk>
+  Christian Brauner <brauner@kernel.org>
+  Matthew Wilcox (Oracle) <willy@infradead.org>
+  Andrew Morton <akpm@linux-foundation.org>
+  kvm@vger.kernel.org
+  linux-arm-kernel@lists.infradead.org
+  kvmarm@lists.linux.dev
+  linux-mips@vger.kernel.org
+  linuxppc-dev@lists.ozlabs.org
+  kvm-riscv@lists.infradead.org
+  linux-riscv@lists.infradead.org
+  linux-fsdevel@vger.kernel.org
+  linux-mm@kvack.org
+  linux-kernel@vger.kernel.org
+  Xiaoyao Li <xiaoyao.li@intel.com>
+  Xu Yilun <yilun.xu@intel.com>
+  Chao Peng <chao.p.peng@linux.intel.com>
+  Jarkko Sakkinen <jarkko@kernel.org>
+  Anish Moorthy <amoorthy@google.com>
+  David Matlack <dmatlack@google.com>
+  Yu Zhang <yu.c.zhang@linux.intel.com>
+  Isaku Yamahata <isaku.yamahata@intel.com>
+ " Micka\303\253l Sala\303\274n <mic@digikod.net>"
+  Vlastimil Babka <vbabka@suse.cz>
+  Vishal Annapurve <vannapurve@google.com>
+  Ackerley Tng <ackerleytng@google.com>
+  Maciej Szmigiero <mail@maciej.szmigiero.name>
+  David Hildenbrand <david@redhat.com>
+  Quentin Perret <qperret@google.com>
+  Michael Roth <michael.roth@amd.com>
+  Wang <wei.w.wang@intel.com>
+  Liam Merwick <liam.merwick@oracle.com>
+  Isaku Yamahata <isaku.yamahata@gmail.com>
+ " Kirill A . Shutemov <kirill.shutemov@linux.intel.com>\0"
  "\00:1\0"
  "b\0"
  "On Thu, Nov 02, 2023, Fuad Tabba wrote:\n"
- "> On Wed, Nov 1, 2023 at 9:55?PM Sean Christopherson <seanjc@google.com> wrote:\n"
+ "> On Wed, Nov 1, 2023 at 9:55\342\200\257PM Sean Christopherson <seanjc@google.com> wrote:\n"
  "> > E.g. a misbehaving userspace could prematurely delete a memslot.  And the more\n"
  "> > fun example is intrahost migration, where the plan is to allow pointing multiple\n"
  "> > guest_memfd files at a single guest_memfd inode:\n"
- "> > https://lore.kernel.org/all/cover.1691446946.git.ackerleytng at google.com\n"
+ "> > https://lore.kernel.org/all/cover.1691446946.git.ackerleytng@google.com\n"
  "> >\n"
  "> > There was a lot of discussion for this, but it's scattered all over the place.\n"
  "> > The TL;DR is is that the inode will represent physical memory, and a file will\n"
@@ -24,14 +67,19 @@
  "> > isn't reclaimed until the inode is truncated/punched.\n"
  "> >\n"
  "> > I _think_ this reflects the most recent plan from the guest_memfd side:\n"
- "> > https://lore.kernel.org/all/1233d749211c08d51f9ca5d427938d47f008af1f.1689893403.git.isaku.yamahata at intel.com\n"
+ "> > https://lore.kernel.org/all/1233d749211c08d51f9ca5d427938d47f008af1f.1689893403.git.isaku.yamahata@intel.com\n"
  "\n"
  "Doh, sitting in my TODO folder...\n"
  "\n"
- "https://lore.kernel.org/all/20231016115028.996656-1-michael.roth at amd.com\n"
+ "https://lore.kernel.org/all/20231016115028.996656-1-michael.roth@amd.com\n"
  "\n"
  "> Thanks for pointing that out. I think this might be the way to go.\n"
  "> I'll have a closer look at this and see how to get it to work with\n"
- > pKVM.
+ "> pKVM.\n"
+ "\n"
+ "_______________________________________________\n"
+ "linux-riscv mailing list\n"
+ "linux-riscv@lists.infradead.org\n"
+ http://lists.infradead.org/mailman/listinfo/linux-riscv
 
-110ef2b4bc84174267e26f60fc95060e0cec67199b3d5e0a1ddab4401033dff4
+eda5d58f19aded51b1b3de8084e58c78b96b92f57d2968be349e369d38fca701

diff --git a/a/1.txt b/N3/1.txt
index 6590031..4684799 100644
--- a/a/1.txt
+++ b/N3/1.txt
@@ -1,9 +1,9 @@
 On Thu, Nov 02, 2023, Fuad Tabba wrote:
-> On Wed, Nov 1, 2023 at 9:55?PM Sean Christopherson <seanjc@google.com> wrote:
+> On Wed, Nov 1, 2023 at 9:55 PM Sean Christopherson <seanjc@google.com> wrote:
 > > E.g. a misbehaving userspace could prematurely delete a memslot.  And the more
 > > fun example is intrahost migration, where the plan is to allow pointing multiple
 > > guest_memfd files at a single guest_memfd inode:
-> > https://lore.kernel.org/all/cover.1691446946.git.ackerleytng at google.com
+> > https://lore.kernel.org/all/cover.1691446946.git.ackerleytng@google.com
 > >
 > > There was a lot of discussion for this, but it's scattered all over the place.
 > > The TL;DR is is that the inode will represent physical memory, and a file will
@@ -11,11 +11,11 @@ On Thu, Nov 02, 2023, Fuad Tabba wrote:
 > > isn't reclaimed until the inode is truncated/punched.
 > >
 > > I _think_ this reflects the most recent plan from the guest_memfd side:
-> > https://lore.kernel.org/all/1233d749211c08d51f9ca5d427938d47f008af1f.1689893403.git.isaku.yamahata at intel.com
+> > https://lore.kernel.org/all/1233d749211c08d51f9ca5d427938d47f008af1f.1689893403.git.isaku.yamahata@intel.com
 
 Doh, sitting in my TODO folder...
 
-https://lore.kernel.org/all/20231016115028.996656-1-michael.roth at amd.com
+https://lore.kernel.org/all/20231016115028.996656-1-michael.roth@amd.com
 
 > Thanks for pointing that out. I think this might be the way to go.
 > I'll have a closer look at this and see how to get it to work with
diff --git a/a/content_digest b/N3/content_digest
index 9658dd5..1d64e33 100644
--- a/a/content_digest
+++ b/N3/content_digest
@@ -6,17 +6,44 @@
  "ref\0ZULJYg5cf1UrNq3e@google.com\0"
  "ref\0CA+EHjTzGzXnfXHh0m5iHt9m3BxerkUS56EVPDA_az6n2FRnk3w@mail.gmail.com\0"
  "From\0Sean Christopherson <seanjc@google.com>\0"
- "Subject\0[PATCH v13 16/35] KVM: Add KVM_CREATE_GUEST_MEMFD ioctl() for guest-specific backing memory\0"
+ "Subject\0Re: [PATCH v13 16/35] KVM: Add KVM_CREATE_GUEST_MEMFD ioctl() for guest-specific backing memory\0"
  "Date\0Fri, 3 Nov 2023 16:17:23 -0700\0"
- "To\0kvm-riscv@lists.infradead.org\0"
+ "To\0Fuad Tabba <tabba@google.com>\0"
+ "Cc\0kvm@vger.kernel.org"
+  David Hildenbrand <david@redhat.com>
+  linux-kernel@vger.kernel.org
+  linux-mm@kvack.org
+  Chao Peng <chao.p.peng@linux.intel.com>
+  linux-riscv@lists.infradead.org
+  Isaku Yamahata <isaku.yamahata@gmail.com>
+  Marc Zyngier <maz@kernel.org>
+  Huacai Chen <chenhuacai@kernel.org>
+  Xiaoyao Li <xiaoyao.li@intel.com>
+  Matthew Wilcox (Oracle) <willy@infradead.org>
+  Wang <wei.w.wang@intel.com>
+  Vlastimil Babka <vbabka@suse.cz>
+  Yu Zhang <yu.c.zhang@linux.intel.com>
+  Maciej Szmigiero <mail@maciej.szmigiero.name>
+  Albert Ou <aou@eecs.berkeley.edu>
+  Michael Roth <michael.roth@amd.com>
+  Ackerley Tng <ackerleytng@google.com>
+  Alexander Viro <viro@zeniv.linux.org.uk>
+  Paul Walmsley <paul.walmsley@sifive.com>
+  kvmarm@lists.linux.dev
+  linux-arm-kernel@lists.infradead.org
+ " Micka\303\253l Sala\303\274n <mic@digikod.net>"
+  Isaku Yamahata <isaku.yamahata@intel.com>
+  Christian Brauner <brauner@kernel.org>
+  Quentin Perret <qperret@google.com>
+ " Liam Merwick <liam.merwick@oracl>\0"
  "\00:1\0"
  "b\0"
  "On Thu, Nov 02, 2023, Fuad Tabba wrote:\n"
- "> On Wed, Nov 1, 2023 at 9:55?PM Sean Christopherson <seanjc@google.com> wrote:\n"
+ "> On Wed, Nov 1, 2023 at 9:55\342\200\257PM Sean Christopherson <seanjc@google.com> wrote:\n"
  "> > E.g. a misbehaving userspace could prematurely delete a memslot.  And the more\n"
  "> > fun example is intrahost migration, where the plan is to allow pointing multiple\n"
  "> > guest_memfd files at a single guest_memfd inode:\n"
- "> > https://lore.kernel.org/all/cover.1691446946.git.ackerleytng at google.com\n"
+ "> > https://lore.kernel.org/all/cover.1691446946.git.ackerleytng@google.com\n"
  "> >\n"
  "> > There was a lot of discussion for this, but it's scattered all over the place.\n"
  "> > The TL;DR is is that the inode will represent physical memory, and a file will\n"
@@ -24,14 +51,14 @@
  "> > isn't reclaimed until the inode is truncated/punched.\n"
  "> >\n"
  "> > I _think_ this reflects the most recent plan from the guest_memfd side:\n"
- "> > https://lore.kernel.org/all/1233d749211c08d51f9ca5d427938d47f008af1f.1689893403.git.isaku.yamahata at intel.com\n"
+ "> > https://lore.kernel.org/all/1233d749211c08d51f9ca5d427938d47f008af1f.1689893403.git.isaku.yamahata@intel.com\n"
  "\n"
  "Doh, sitting in my TODO folder...\n"
  "\n"
- "https://lore.kernel.org/all/20231016115028.996656-1-michael.roth at amd.com\n"
+ "https://lore.kernel.org/all/20231016115028.996656-1-michael.roth@amd.com\n"
  "\n"
  "> Thanks for pointing that out. I think this might be the way to go.\n"
  "> I'll have a closer look at this and see how to get it to work with\n"
  > pKVM.
 
-110ef2b4bc84174267e26f60fc95060e0cec67199b3d5e0a1ddab4401033dff4
+2d087ead2153809a744566fafaec1e8880cb8b26ea98a64308abe026922f66af

diff --git a/a/1.txt b/N4/1.txt
index 6590031..43dfb79 100644
--- a/a/1.txt
+++ b/N4/1.txt
@@ -1,9 +1,9 @@
 On Thu, Nov 02, 2023, Fuad Tabba wrote:
-> On Wed, Nov 1, 2023 at 9:55?PM Sean Christopherson <seanjc@google.com> wrote:
+> On Wed, Nov 1, 2023 at 9:55 PM Sean Christopherson <seanjc@google.com> wrote:
 > > E.g. a misbehaving userspace could prematurely delete a memslot.  And the more
 > > fun example is intrahost migration, where the plan is to allow pointing multiple
 > > guest_memfd files at a single guest_memfd inode:
-> > https://lore.kernel.org/all/cover.1691446946.git.ackerleytng at google.com
+> > https://lore.kernel.org/all/cover.1691446946.git.ackerleytng@google.com
 > >
 > > There was a lot of discussion for this, but it's scattered all over the place.
 > > The TL;DR is is that the inode will represent physical memory, and a file will
@@ -11,12 +11,17 @@ On Thu, Nov 02, 2023, Fuad Tabba wrote:
 > > isn't reclaimed until the inode is truncated/punched.
 > >
 > > I _think_ this reflects the most recent plan from the guest_memfd side:
-> > https://lore.kernel.org/all/1233d749211c08d51f9ca5d427938d47f008af1f.1689893403.git.isaku.yamahata at intel.com
+> > https://lore.kernel.org/all/1233d749211c08d51f9ca5d427938d47f008af1f.1689893403.git.isaku.yamahata@intel.com
 
 Doh, sitting in my TODO folder...
 
-https://lore.kernel.org/all/20231016115028.996656-1-michael.roth at amd.com
+https://lore.kernel.org/all/20231016115028.996656-1-michael.roth@amd.com
 
 > Thanks for pointing that out. I think this might be the way to go.
 > I'll have a closer look at this and see how to get it to work with
 > pKVM.
+
+_______________________________________________
+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 9658dd5..517b70b 100644
--- a/a/content_digest
+++ b/N4/content_digest
@@ -6,17 +6,60 @@
  "ref\0ZULJYg5cf1UrNq3e@google.com\0"
  "ref\0CA+EHjTzGzXnfXHh0m5iHt9m3BxerkUS56EVPDA_az6n2FRnk3w@mail.gmail.com\0"
  "From\0Sean Christopherson <seanjc@google.com>\0"
- "Subject\0[PATCH v13 16/35] KVM: Add KVM_CREATE_GUEST_MEMFD ioctl() for guest-specific backing memory\0"
+ "Subject\0Re: [PATCH v13 16/35] KVM: Add KVM_CREATE_GUEST_MEMFD ioctl() for guest-specific backing memory\0"
  "Date\0Fri, 3 Nov 2023 16:17:23 -0700\0"
- "To\0kvm-riscv@lists.infradead.org\0"
+ "To\0Fuad Tabba <tabba@google.com>\0"
+ "Cc\0Paolo Bonzini <pbonzini@redhat.com>"
+  Marc Zyngier <maz@kernel.org>
+  Oliver Upton <oliver.upton@linux.dev>
+  Huacai Chen <chenhuacai@kernel.org>
+  Michael Ellerman <mpe@ellerman.id.au>
+  Anup Patel <anup@brainfault.org>
+  Paul Walmsley <paul.walmsley@sifive.com>
+  Palmer Dabbelt <palmer@dabbelt.com>
+  Albert Ou <aou@eecs.berkeley.edu>
+  Alexander Viro <viro@zeniv.linux.org.uk>
+  Christian Brauner <brauner@kernel.org>
+  Matthew Wilcox (Oracle) <willy@infradead.org>
+  Andrew Morton <akpm@linux-foundation.org>
+  kvm@vger.kernel.org
+  linux-arm-kernel@lists.infradead.org
+  kvmarm@lists.linux.dev
+  linux-mips@vger.kernel.org
+  linuxppc-dev@lists.ozlabs.org
+  kvm-riscv@lists.infradead.org
+  linux-riscv@lists.infradead.org
+  linux-fsdevel@vger.kernel.org
+  linux-mm@kvack.org
+  linux-kernel@vger.kernel.org
+  Xiaoyao Li <xiaoyao.li@intel.com>
+  Xu Yilun <yilun.xu@intel.com>
+  Chao Peng <chao.p.peng@linux.intel.com>
+  Jarkko Sakkinen <jarkko@kernel.org>
+  Anish Moorthy <amoorthy@google.com>
+  David Matlack <dmatlack@google.com>
+  Yu Zhang <yu.c.zhang@linux.intel.com>
+  Isaku Yamahata <isaku.yamahata@intel.com>
+ " Micka\303\253l Sala\303\274n <mic@digikod.net>"
+  Vlastimil Babka <vbabka@suse.cz>
+  Vishal Annapurve <vannapurve@google.com>
+  Ackerley Tng <ackerleytng@google.com>
+  Maciej Szmigiero <mail@maciej.szmigiero.name>
+  David Hildenbrand <david@redhat.com>
+  Quentin Perret <qperret@google.com>
+  Michael Roth <michael.roth@amd.com>
+  Wang <wei.w.wang@intel.com>
+  Liam Merwick <liam.merwick@oracle.com>
+  Isaku Yamahata <isaku.yamahata@gmail.com>
+ " Kirill A . Shutemov <kirill.shutemov@linux.intel.com>\0"
  "\00:1\0"
  "b\0"
  "On Thu, Nov 02, 2023, Fuad Tabba wrote:\n"
- "> On Wed, Nov 1, 2023 at 9:55?PM Sean Christopherson <seanjc@google.com> wrote:\n"
+ "> On Wed, Nov 1, 2023 at 9:55\342\200\257PM Sean Christopherson <seanjc@google.com> wrote:\n"
  "> > E.g. a misbehaving userspace could prematurely delete a memslot.  And the more\n"
  "> > fun example is intrahost migration, where the plan is to allow pointing multiple\n"
  "> > guest_memfd files at a single guest_memfd inode:\n"
- "> > https://lore.kernel.org/all/cover.1691446946.git.ackerleytng at google.com\n"
+ "> > https://lore.kernel.org/all/cover.1691446946.git.ackerleytng@google.com\n"
  "> >\n"
  "> > There was a lot of discussion for this, but it's scattered all over the place.\n"
  "> > The TL;DR is is that the inode will represent physical memory, and a file will\n"
@@ -24,14 +67,19 @@
  "> > isn't reclaimed until the inode is truncated/punched.\n"
  "> >\n"
  "> > I _think_ this reflects the most recent plan from the guest_memfd side:\n"
- "> > https://lore.kernel.org/all/1233d749211c08d51f9ca5d427938d47f008af1f.1689893403.git.isaku.yamahata at intel.com\n"
+ "> > https://lore.kernel.org/all/1233d749211c08d51f9ca5d427938d47f008af1f.1689893403.git.isaku.yamahata@intel.com\n"
  "\n"
  "Doh, sitting in my TODO folder...\n"
  "\n"
- "https://lore.kernel.org/all/20231016115028.996656-1-michael.roth at amd.com\n"
+ "https://lore.kernel.org/all/20231016115028.996656-1-michael.roth@amd.com\n"
  "\n"
  "> Thanks for pointing that out. I think this might be the way to go.\n"
  "> I'll have a closer look at this and see how to get it to work with\n"
- > pKVM.
+ "> pKVM.\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
 
-110ef2b4bc84174267e26f60fc95060e0cec67199b3d5e0a1ddab4401033dff4
+991009a03a081865762b68a04b355efb41ce614558281561c6e9ee3579c0228f

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.