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.