diff for duplicates of <ZULJYg5cf1UrNq3e@google.com> diff --git a/a/1.txt b/N1/1.txt index c95cd48..618025a 100644 --- a/a/1.txt +++ b/N1/1.txt @@ -58,7 +58,7 @@ that is still owned by guest_memfd. 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 @@ -66,4 +66,4 @@ represent a given "struct kvm" instance's view of that memory. And so the memor 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 diff --git a/a/content_digest b/N1/content_digest index dfa738a..645f484 100644 --- a/a/content_digest +++ b/N1/content_digest @@ -4,9 +4,52 @@ "ref\0ZUF8A5KpwpA6IKUH@google.com\0" "ref\0CA+EHjTwTT9cFzYTtwT43nLJS01Sgt0NqzUgKAnfo2fiV3tEvXg@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\0Wed, 1 Nov 2023 14:55:46 -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 Wed, Nov 01, 2023, Fuad Tabba wrote:\n" @@ -69,7 +112,7 @@ "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" @@ -77,6 +120,6 @@ "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 + https://lore.kernel.org/all/1233d749211c08d51f9ca5d427938d47f008af1f.1689893403.git.isaku.yamahata@intel.com -1f0c36f4bc3674583f26b85d0a5bec59169bf54ee8876f494e50738fb7d4a6b0 +15cf3437102b310ae359505f0db8de37a4db3a7b2198778bede50a269a432198
diff --git a/a/1.txt b/N2/1.txt index c95cd48..a745dfb 100644 --- a/a/1.txt +++ b/N2/1.txt @@ -58,7 +58,7 @@ that is still owned by guest_memfd. 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 @@ -66,4 +66,9 @@ represent a given "struct kvm" instance's view of that memory. And so the memor 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 + +_______________________________________________ +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 dfa738a..5b3eb5c 100644 --- a/a/content_digest +++ b/N2/content_digest @@ -4,9 +4,52 @@ "ref\0ZUF8A5KpwpA6IKUH@google.com\0" "ref\0CA+EHjTwTT9cFzYTtwT43nLJS01Sgt0NqzUgKAnfo2fiV3tEvXg@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\0Wed, 1 Nov 2023 14:55:46 -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 Wed, Nov 01, 2023, Fuad Tabba wrote:\n" @@ -69,7 +112,7 @@ "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" @@ -77,6 +120,11 @@ "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 + "https://lore.kernel.org/all/1233d749211c08d51f9ca5d427938d47f008af1f.1689893403.git.isaku.yamahata@intel.com\n" + "\n" + "_______________________________________________\n" + "linux-riscv mailing list\n" + "linux-riscv@lists.infradead.org\n" + http://lists.infradead.org/mailman/listinfo/linux-riscv -1f0c36f4bc3674583f26b85d0a5bec59169bf54ee8876f494e50738fb7d4a6b0 +7174be36da0c317ac121af6c33d715330686531845606d9c7f9433e752be7fc4
diff --git a/a/1.txt b/N3/1.txt index c95cd48..618025a 100644 --- a/a/1.txt +++ b/N3/1.txt @@ -58,7 +58,7 @@ that is still owned by guest_memfd. 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 @@ -66,4 +66,4 @@ represent a given "struct kvm" instance's view of that memory. And so the memor 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 diff --git a/a/content_digest b/N3/content_digest index dfa738a..c38c639 100644 --- a/a/content_digest +++ b/N3/content_digest @@ -4,9 +4,36 @@ "ref\0ZUF8A5KpwpA6IKUH@google.com\0" "ref\0CA+EHjTwTT9cFzYTtwT43nLJS01Sgt0NqzUgKAnfo2fiV3tEvXg@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\0Wed, 1 Nov 2023 14:55:46 -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 Wed, Nov 01, 2023, Fuad Tabba wrote:\n" @@ -69,7 +96,7 @@ "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" @@ -77,6 +104,6 @@ "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 + https://lore.kernel.org/all/1233d749211c08d51f9ca5d427938d47f008af1f.1689893403.git.isaku.yamahata@intel.com -1f0c36f4bc3674583f26b85d0a5bec59169bf54ee8876f494e50738fb7d4a6b0 +2e2497e2470d954921c71d5db9b9324f067c17db1d55746ed47541fa50597df3
diff --git a/a/1.txt b/N4/1.txt index c95cd48..7e943a6 100644 --- a/a/1.txt +++ b/N4/1.txt @@ -58,7 +58,7 @@ that is still owned by guest_memfd. 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 @@ -66,4 +66,9 @@ represent a given "struct kvm" instance's view of that memory. And so the memor 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 + +_______________________________________________ +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 dfa738a..091b1fb 100644 --- a/a/content_digest +++ b/N4/content_digest @@ -4,9 +4,52 @@ "ref\0ZUF8A5KpwpA6IKUH@google.com\0" "ref\0CA+EHjTwTT9cFzYTtwT43nLJS01Sgt0NqzUgKAnfo2fiV3tEvXg@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\0Wed, 1 Nov 2023 14:55:46 -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 Wed, Nov 01, 2023, Fuad Tabba wrote:\n" @@ -69,7 +112,7 @@ "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" @@ -77,6 +120,11 @@ "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 + "https://lore.kernel.org/all/1233d749211c08d51f9ca5d427938d47f008af1f.1689893403.git.isaku.yamahata@intel.com\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 -1f0c36f4bc3674583f26b85d0a5bec59169bf54ee8876f494e50738fb7d4a6b0 +4a986a56411cf5c740bd80f27f0dfc59126019b9b87a636402e2930e168ca1b3
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.