diff for duplicates of <ZUJVfCkIYYFp5VwG@google.com> diff --git a/a/1.txt b/N1/1.txt index 42e2aa6..2cee692 100644 --- a/a/1.txt +++ b/N1/1.txt @@ -30,7 +30,7 @@ On Wed, Nov 01, 2023, Xiaoyao Li wrote: > > allowing hugepages, e.g. silent failure due to lack of THP or unaligned size, > > and there's precedent in the form of MADV_HUGEPAGE. > > -> > [*] https://lore.kernel.org/all/84a908ae-04c7-51c7-c9a8-119e1933a189 at redhat.com +> > [*] https://lore.kernel.org/all/84a908ae-04c7-51c7-c9a8-119e1933a189@redhat.com > > But it's different than MADV_HUGEPAGE, in a way. Per my understanding, the > failure of MADV_HUGEPAGE is not fatal, user space can ignore it and diff --git a/a/content_digest b/N1/content_digest index f16738b..e2ece4c 100644 --- a/a/content_digest +++ b/N1/content_digest @@ -4,9 +4,52 @@ "ref\0ZUEML6oJXDCFJ9fg@google.com\0" "ref\092ba7ddd-2bc8-4a8d-bd67-d6614b21914f@intel.com\0" "From\0Sean Christopherson <seanjc@google.com>\0" - "Subject\0[PATCH v13 17/35] KVM: Add transparent hugepage support for dedicated guest memory\0" + "Subject\0Re: [PATCH v13 17/35] KVM: Add transparent hugepage support for dedicated guest memory\0" "Date\0Wed, 1 Nov 2023 06:41:45 -0700\0" - "To\0kvm-riscv@lists.infradead.org\0" + "To\0Xiaoyao Li <xiaoyao.li@intel.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 + Xu Yilun <yilun.xu@intel.com> + Chao Peng <chao.p.peng@linux.intel.com> + Fuad Tabba <tabba@google.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, Xiaoyao Li wrote:\n" @@ -41,7 +84,7 @@ "> > allowing hugepages, e.g. silent failure due to lack of THP or unaligned size,\n" "> > and there's precedent in the form of MADV_HUGEPAGE.\n" "> > \n" - "> > [*] https://lore.kernel.org/all/84a908ae-04c7-51c7-c9a8-119e1933a189 at redhat.com\n" + "> > [*] https://lore.kernel.org/all/84a908ae-04c7-51c7-c9a8-119e1933a189@redhat.com\n" "> \n" "> But it's different than MADV_HUGEPAGE, in a way. Per my understanding, the\n" "> failure of MADV_HUGEPAGE is not fatal, user space can ignore it and\n" @@ -79,4 +122,4 @@ "a hint, but weaker than a requirement. And if/when KVM supports a dedicated memory\n" pool of some kind, then we can add KVM_GUEST_MEMFD_REQUIRE_HUGEPAGE. -e5e776f6445237f204d4d45cda3683a6c6c3c806cc4ad4dfae3bc509dc3f7a38 +dbaa0c8c9158217aacfba79010b944bca33a1483aa06264f8e6825d3f3928a8f
diff --git a/a/1.txt b/N2/1.txt index 42e2aa6..49357bd 100644 --- a/a/1.txt +++ b/N2/1.txt @@ -30,7 +30,7 @@ On Wed, Nov 01, 2023, Xiaoyao Li wrote: > > allowing hugepages, e.g. silent failure due to lack of THP or unaligned size, > > and there's precedent in the form of MADV_HUGEPAGE. > > -> > [*] https://lore.kernel.org/all/84a908ae-04c7-51c7-c9a8-119e1933a189 at redhat.com +> > [*] https://lore.kernel.org/all/84a908ae-04c7-51c7-c9a8-119e1933a189@redhat.com > > But it's different than MADV_HUGEPAGE, in a way. Per my understanding, the > failure of MADV_HUGEPAGE is not fatal, user space can ignore it and @@ -67,3 +67,8 @@ or KVM_GUEST_MEMFD_HUGEPAGES flag, but I wanted the name to convey that KVM does (yet) guarantee hugepages. I.e. KVM_GUEST_MEMFD_ALLOW_HUGEPAGE is stronger than a hint, but weaker than a requirement. And if/when KVM supports a dedicated memory pool of some kind, then we can add KVM_GUEST_MEMFD_REQUIRE_HUGEPAGE. + +_______________________________________________ +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 f16738b..1fdd345 100644 --- a/a/content_digest +++ b/N2/content_digest @@ -4,9 +4,52 @@ "ref\0ZUEML6oJXDCFJ9fg@google.com\0" "ref\092ba7ddd-2bc8-4a8d-bd67-d6614b21914f@intel.com\0" "From\0Sean Christopherson <seanjc@google.com>\0" - "Subject\0[PATCH v13 17/35] KVM: Add transparent hugepage support for dedicated guest memory\0" + "Subject\0Re: [PATCH v13 17/35] KVM: Add transparent hugepage support for dedicated guest memory\0" "Date\0Wed, 1 Nov 2023 06:41:45 -0700\0" - "To\0kvm-riscv@lists.infradead.org\0" + "To\0Xiaoyao Li <xiaoyao.li@intel.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 + Xu Yilun <yilun.xu@intel.com> + Chao Peng <chao.p.peng@linux.intel.com> + Fuad Tabba <tabba@google.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, Xiaoyao Li wrote:\n" @@ -41,7 +84,7 @@ "> > allowing hugepages, e.g. silent failure due to lack of THP or unaligned size,\n" "> > and there's precedent in the form of MADV_HUGEPAGE.\n" "> > \n" - "> > [*] https://lore.kernel.org/all/84a908ae-04c7-51c7-c9a8-119e1933a189 at redhat.com\n" + "> > [*] https://lore.kernel.org/all/84a908ae-04c7-51c7-c9a8-119e1933a189@redhat.com\n" "> \n" "> But it's different than MADV_HUGEPAGE, in a way. Per my understanding, the\n" "> failure of MADV_HUGEPAGE is not fatal, user space can ignore it and\n" @@ -77,6 +120,11 @@ "or KVM_GUEST_MEMFD_HUGEPAGES flag, but I wanted the name to convey that KVM doesn't\n" "(yet) guarantee hugepages. I.e. KVM_GUEST_MEMFD_ALLOW_HUGEPAGE is stronger than\n" "a hint, but weaker than a requirement. And if/when KVM supports a dedicated memory\n" - pool of some kind, then we can add KVM_GUEST_MEMFD_REQUIRE_HUGEPAGE. + "pool of some kind, then we can add KVM_GUEST_MEMFD_REQUIRE_HUGEPAGE.\n" + "\n" + "_______________________________________________\n" + "linux-riscv mailing list\n" + "linux-riscv@lists.infradead.org\n" + http://lists.infradead.org/mailman/listinfo/linux-riscv -e5e776f6445237f204d4d45cda3683a6c6c3c806cc4ad4dfae3bc509dc3f7a38 +e04b32b14865476d3c74e653f45a92dc90b31ab81db6a05eff1a8975d92a68dc
diff --git a/a/1.txt b/N3/1.txt index 42e2aa6..2cee692 100644 --- a/a/1.txt +++ b/N3/1.txt @@ -30,7 +30,7 @@ On Wed, Nov 01, 2023, Xiaoyao Li wrote: > > allowing hugepages, e.g. silent failure due to lack of THP or unaligned size, > > and there's precedent in the form of MADV_HUGEPAGE. > > -> > [*] https://lore.kernel.org/all/84a908ae-04c7-51c7-c9a8-119e1933a189 at redhat.com +> > [*] https://lore.kernel.org/all/84a908ae-04c7-51c7-c9a8-119e1933a189@redhat.com > > But it's different than MADV_HUGEPAGE, in a way. Per my understanding, the > failure of MADV_HUGEPAGE is not fatal, user space can ignore it and diff --git a/a/content_digest b/N3/content_digest index f16738b..1ecfc84 100644 --- a/a/content_digest +++ b/N3/content_digest @@ -4,9 +4,36 @@ "ref\0ZUEML6oJXDCFJ9fg@google.com\0" "ref\092ba7ddd-2bc8-4a8d-bd67-d6614b21914f@intel.com\0" "From\0Sean Christopherson <seanjc@google.com>\0" - "Subject\0[PATCH v13 17/35] KVM: Add transparent hugepage support for dedicated guest memory\0" + "Subject\0Re: [PATCH v13 17/35] KVM: Add transparent hugepage support for dedicated guest memory\0" "Date\0Wed, 1 Nov 2023 06:41:45 -0700\0" - "To\0kvm-riscv@lists.infradead.org\0" + "To\0Xiaoyao Li <xiaoyao.li@intel.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> + Matthew Wilcox (Oracle) <willy@infradead.org> + Wang <wei.w.wang@intel.com> + Fuad Tabba <tabba@google.com> + Yu Zhang <yu.c.zhang@linux.intel.com> + Maciej Szmigiero <mail@maciej.szmigiero.name> + Albert Ou <aou@eecs.berkeley.edu> + Vlastimil Babka <vbabka@suse.cz> + 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@oracle.co>\0" "\00:1\0" "b\0" "On Wed, Nov 01, 2023, Xiaoyao Li wrote:\n" @@ -41,7 +68,7 @@ "> > allowing hugepages, e.g. silent failure due to lack of THP or unaligned size,\n" "> > and there's precedent in the form of MADV_HUGEPAGE.\n" "> > \n" - "> > [*] https://lore.kernel.org/all/84a908ae-04c7-51c7-c9a8-119e1933a189 at redhat.com\n" + "> > [*] https://lore.kernel.org/all/84a908ae-04c7-51c7-c9a8-119e1933a189@redhat.com\n" "> \n" "> But it's different than MADV_HUGEPAGE, in a way. Per my understanding, the\n" "> failure of MADV_HUGEPAGE is not fatal, user space can ignore it and\n" @@ -79,4 +106,4 @@ "a hint, but weaker than a requirement. And if/when KVM supports a dedicated memory\n" pool of some kind, then we can add KVM_GUEST_MEMFD_REQUIRE_HUGEPAGE. -e5e776f6445237f204d4d45cda3683a6c6c3c806cc4ad4dfae3bc509dc3f7a38 +38e0ecc7ee42293abfa84551f871da5d036bb13ade562f0e8a7edc744b4529c4
diff --git a/a/1.txt b/N4/1.txt index 42e2aa6..c3c3976 100644 --- a/a/1.txt +++ b/N4/1.txt @@ -30,7 +30,7 @@ On Wed, Nov 01, 2023, Xiaoyao Li wrote: > > allowing hugepages, e.g. silent failure due to lack of THP or unaligned size, > > and there's precedent in the form of MADV_HUGEPAGE. > > -> > [*] https://lore.kernel.org/all/84a908ae-04c7-51c7-c9a8-119e1933a189 at redhat.com +> > [*] https://lore.kernel.org/all/84a908ae-04c7-51c7-c9a8-119e1933a189@redhat.com > > But it's different than MADV_HUGEPAGE, in a way. Per my understanding, the > failure of MADV_HUGEPAGE is not fatal, user space can ignore it and @@ -67,3 +67,8 @@ or KVM_GUEST_MEMFD_HUGEPAGES flag, but I wanted the name to convey that KVM does (yet) guarantee hugepages. I.e. KVM_GUEST_MEMFD_ALLOW_HUGEPAGE is stronger than a hint, but weaker than a requirement. And if/when KVM supports a dedicated memory pool of some kind, then we can add KVM_GUEST_MEMFD_REQUIRE_HUGEPAGE. + +_______________________________________________ +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 f16738b..349a3a4 100644 --- a/a/content_digest +++ b/N4/content_digest @@ -4,9 +4,52 @@ "ref\0ZUEML6oJXDCFJ9fg@google.com\0" "ref\092ba7ddd-2bc8-4a8d-bd67-d6614b21914f@intel.com\0" "From\0Sean Christopherson <seanjc@google.com>\0" - "Subject\0[PATCH v13 17/35] KVM: Add transparent hugepage support for dedicated guest memory\0" + "Subject\0Re: [PATCH v13 17/35] KVM: Add transparent hugepage support for dedicated guest memory\0" "Date\0Wed, 1 Nov 2023 06:41:45 -0700\0" - "To\0kvm-riscv@lists.infradead.org\0" + "To\0Xiaoyao Li <xiaoyao.li@intel.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 + Xu Yilun <yilun.xu@intel.com> + Chao Peng <chao.p.peng@linux.intel.com> + Fuad Tabba <tabba@google.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, Xiaoyao Li wrote:\n" @@ -41,7 +84,7 @@ "> > allowing hugepages, e.g. silent failure due to lack of THP or unaligned size,\n" "> > and there's precedent in the form of MADV_HUGEPAGE.\n" "> > \n" - "> > [*] https://lore.kernel.org/all/84a908ae-04c7-51c7-c9a8-119e1933a189 at redhat.com\n" + "> > [*] https://lore.kernel.org/all/84a908ae-04c7-51c7-c9a8-119e1933a189@redhat.com\n" "> \n" "> But it's different than MADV_HUGEPAGE, in a way. Per my understanding, the\n" "> failure of MADV_HUGEPAGE is not fatal, user space can ignore it and\n" @@ -77,6 +120,11 @@ "or KVM_GUEST_MEMFD_HUGEPAGES flag, but I wanted the name to convey that KVM doesn't\n" "(yet) guarantee hugepages. I.e. KVM_GUEST_MEMFD_ALLOW_HUGEPAGE is stronger than\n" "a hint, but weaker than a requirement. And if/when KVM supports a dedicated memory\n" - pool of some kind, then we can add KVM_GUEST_MEMFD_REQUIRE_HUGEPAGE. + "pool of some kind, then we can add KVM_GUEST_MEMFD_REQUIRE_HUGEPAGE.\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 -e5e776f6445237f204d4d45cda3683a6c6c3c806cc4ad4dfae3bc509dc3f7a38 +77cfd76c2c60cb9660d2fa4197b5d7c8792ce1dfc00f4c86c3afec638b5ddfc6
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.