diff for duplicates of <ZRtxoaJdVF1C2Mvy@google.com> diff --git a/a/1.txt b/N1/1.txt index 2ef94c3..6f2b2c5 100644 --- a/a/1.txt +++ b/N1/1.txt @@ -1,5 +1,5 @@ On Mon, Oct 02, 2023, Anish Moorthy wrote: -> On Fri, Sep 22, 2023 at 9:28?AM Sean Christopherson <seanjc@google.com> wrote: +> On Fri, Sep 22, 2023 at 9:28 AM Sean Christopherson <seanjc@google.com> wrote: > > > > > So when exit reason is KVM_EXIT_MEMORY_FAULT, how can we tell which field in > > > the first union is valid? @@ -149,8 +149,8 @@ I'll look at this more closely when I review your series (slowly, slowly getting there). There's no right or wrong answer here, it's more a question of what's the easiest to maintain. -> [a] https://lore.kernel.org/all/20230908222905.1321305-5-amoorthy at google.com/ -> [b] https://lore.kernel.org/all/20230908222905.1321305-11-amoorthy at google.com/ +> [a] https://lore.kernel.org/all/20230908222905.1321305-5-amoorthy@google.com/ +> [b] https://lore.kernel.org/all/20230908222905.1321305-11-amoorthy@google.com/ > > > And if we stop being unnecessarily paranoid, KVM_RUN_MEMORY_FAULT_FILLED can also > > go away. The flag came about in part because *unconditionally* sanitizing diff --git a/a/content_digest b/N1/content_digest index 68d89ec..83fb4c7 100644 --- a/a/content_digest +++ b/N1/content_digest @@ -4,13 +4,40 @@ "ref\0ZQ3AmLO2SYv3DszH@google.com\0" "ref\0CAF7b7mrf-y9DNdsreOAedGJueOThnYE=ascFd4=rvW0Z4rhTQg@mail.gmail.com\0" "From\0Sean Christopherson <seanjc@google.com>\0" - "Subject\0[RFC PATCH v12 07/33] KVM: Add KVM_EXIT_MEMORY_FAULT exit to report faults to userspace\0" + "Subject\0Re: [RFC PATCH v12 07/33] KVM: Add KVM_EXIT_MEMORY_FAULT exit to report faults to userspace\0" "Date\0Mon, 2 Oct 2023 18:42:57 -0700\0" - "To\0kvm-riscv@lists.infradead.org\0" + "To\0Anish Moorthy <amoorthy@google.com>\0" + "Cc\0Xiaoyao Li <xiaoyao.li@intel.com>" + Paolo 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> + kvm@vger.kernel.org + kvmarm@lists.linux.dev + kvm-riscv@lists.infradead.org + linux-kernel@vger.kernel.org + Chao Peng <chao.p.peng@linux.intel.com> + Fuad Tabba <tabba@google.com> + Jarkko Sakkinen <jarkko@kernel.org> + Yu Zhang <yu.c.zhang@linux.intel.com> + Isaku Yamahata <isaku.yamahata@intel.com> + Xu Yilun <yilun.xu@intel.com> + 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>\0" "\00:1\0" "b\0" "On Mon, Oct 02, 2023, Anish Moorthy wrote:\n" - "> On Fri, Sep 22, 2023 at 9:28?AM Sean Christopherson <seanjc@google.com> wrote:\n" + "> On Fri, Sep 22, 2023 at 9:28\342\200\257AM Sean Christopherson <seanjc@google.com> wrote:\n" "> >\n" "> > > So when exit reason is KVM_EXIT_MEMORY_FAULT, how can we tell which field in\n" "> > > the first union is valid?\n" @@ -160,8 +187,8 @@ "there). There's no right or wrong answer here, it's more a question of what's the\n" "easiest to maintain.\n" "\n" - "> [a] https://lore.kernel.org/all/20230908222905.1321305-5-amoorthy at google.com/\n" - "> [b] https://lore.kernel.org/all/20230908222905.1321305-11-amoorthy at google.com/\n" + "> [a] https://lore.kernel.org/all/20230908222905.1321305-5-amoorthy@google.com/\n" + "> [b] https://lore.kernel.org/all/20230908222905.1321305-11-amoorthy@google.com/\n" "> \n" "> > And if we stop being unnecessarily paranoid, KVM_RUN_MEMORY_FAULT_FILLED can also\n" "> > go away. The flag came about in part because *unconditionally* sanitizing\n" @@ -206,4 +233,4 @@ "that we only commit to 100% accuracy for the paths that the two use cases need to\n" work, i.e. the page fault handlers. -853243b1dd6112074e5b4e01fd9fdde04fd25af4ce19834a7aca4b2989a84fc8 +040487f2cff4c081c97b401d3b18deac2a4a1d3fbc2e7c789910bda494c73460
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.