diff for duplicates of <ZUPGu6jroYv3KFPv@google.com> diff --git a/a/1.txt b/N1/1.txt index 992a076..52955ec 100644 --- a/a/1.txt +++ b/N1/1.txt @@ -41,14 +41,14 @@ On Thu, Nov 02, 2023, Kai Huang wrote: > > reasons are preserved across KVM_RUN with vcpu->run->immediate_exit (or with a > > pending signal). > > -> > https://lore.kernel.org/all/ZFFbwOXZ5uI%2Fgdaf at google.com +> > https://lore.kernel.org/all/ZFFbwOXZ5uI%2Fgdaf@google.com > > > > > > Agreed with not to relax to any errno. However using -EFAULT as part of ABI > definition seems a little bit dangerous, e.g., someone could accidentally or > mistakenly return -EFAULT in KVM_RUN at early time and/or in a completely -> different code path, etc. ?-EINTR has well defined meaning, but -EFAULT (which +> different code path, etc. -EINTR has well defined meaning, but -EFAULT (which > is "Bad address") seems doesn't but I am not sure either. :-) KVM has returned -EFAULT since forever, i.e. it's effectively already part of the diff --git a/a/content_digest b/N1/content_digest index dda4ef5..04f5019 100644 --- a/a/content_digest +++ b/N1/content_digest @@ -4,9 +4,53 @@ "ref\0ZUKMsOdg3N9wmEzy@google.com\0" "ref\064e3764e36ba7a00d94cc7db1dea1ef06b620aaf.camel@intel.com\0" "From\0Sean Christopherson <seanjc@google.com>\0" - "Subject\0[PATCH v13 09/35] KVM: Add KVM_EXIT_MEMORY_FAULT exit to report faults to userspace\0" + "Subject\0Re: [PATCH v13 09/35] KVM: Add KVM_EXIT_MEMORY_FAULT exit to report faults to userspace\0" "Date\0Thu, 2 Nov 2023 08:56:43 -0700\0" - "To\0kvm-riscv@lists.infradead.org\0" + "To\0Kai Huang <kai.huang@intel.com>\0" + "Cc\0Xiaoyao Li <xiaoyao.li@intel.com>" + kvm-riscv@lists.infradead.org <kvm-riscv@lists.infradead.org> + mic@digikod.net <mic@digikod.net> + liam.merwick@oracle.com <liam.merwick@oracle.com> + Isaku Yamahata <isaku.yamahata@intel.com> + kvm@vger.kernel.org <kvm@vger.kernel.org> + pbonzini@redhat.com <pbonzini@redhat.com> + kirill.shutemov@linux.intel.com <kirill.shutemov@linux.intel.com> + david@redhat.com <david@redhat.com> + linux-fsdevel@vger.kernel.org <linux-fsdevel@vger.kernel.org> + amoorthy@google.com <amoorthy@google.com> + linuxppc-dev@lists.ozlabs.org <linuxppc-dev@lists.ozlabs.org> + tabba@google.com <tabba@google.com> + kvmarm@lists.linux.dev <kvmarm@lists.linux.dev> + linux-kernel@vger.kernel.org <linux-kernel@vger.kernel.org> + michael.roth@amd.com <michael.roth@amd.com> + viro@zeniv.linux.org.uk <viro@zeniv.linux.org.uk> + oliver.upton@linux.dev <oliver.upton@linux.dev> + chao.p.peng@linux.intel.com <chao.p.peng@linux.intel.com> + palmer@dabbelt.com <palmer@dabbelt.com> + chenhuacai@kernel.org <chenhuacai@kernel.org> + aou@eecs.berkeley.edu <aou@eecs.berkeley.edu> + linux-mips@vger.kernel.org <linux-mips@vger.kernel.org> + mpe@ellerman.id.au <mpe@ellerman.id.au> + Vishal Annapurve <vannapurve@google.com> + vbabka@suse.cz <vbabka@suse.cz> + mail@maciej.szmigiero.name <mail@maciej.szmigiero.name> + linux-riscv@lists.infradead.org <linux-riscv@lists.infradead.org> + maz@kernel.org <maz@kernel.org> + willy@infradead.org <willy@infradead.org> + dmatlack@google.com <dmatlack@google.com> + anup@brainfault.org <anup@brainfault.org> + yu.c.zhang@linux.intel.com <yu.c.zhang@linux.intel.com> + Yilun Xu <yilun.xu@intel.com> + qperret@google.com <qperret@google.com> + brauner@kernel.org <brauner@kernel.org> + isaku.yamahata@gmail.com <isaku.yamahata@gmail.com> + ackerleytng@google.com <ackerleytng@google.com> + jarkko@kernel.org <jarkko@kernel.org> + paul.walmsley@sifive.com <paul.walmsley@sifive.com> + linux-arm-kernel@lists.infradead.org <linux-arm-kernel@lists.infradead.org> + linux-mm@kvack.org <linux-mm@kvack.org> + Wei W Wang <wei.w.wang@intel.com> + " akpm@linux-foundation.org <akpm@linux-foundation.org>\0" "\00:1\0" "b\0" "On Thu, Nov 02, 2023, Kai Huang wrote:\n" @@ -52,14 +96,14 @@ "> > reasons are preserved across KVM_RUN with vcpu->run->immediate_exit (or with a\n" "> > pending signal).\n" "> > \n" - "> > https://lore.kernel.org/all/ZFFbwOXZ5uI%2Fgdaf at google.com\n" + "> > https://lore.kernel.org/all/ZFFbwOXZ5uI%2Fgdaf@google.com\n" "> > \n" "> > \n" "> \n" "> Agreed with not to relax to any errno. However using -EFAULT as part of ABI\n" "> definition seems a little bit dangerous, e.g., someone could accidentally or\n" "> mistakenly return -EFAULT in KVM_RUN at early time and/or in a completely\n" - "> different code path, etc. ?-EINTR has well defined meaning, but -EFAULT (which\n" + "> different code path, etc. \302\240-EINTR has well defined meaning, but -EFAULT (which\n" "> is \"Bad address\") seems doesn't but I am not sure either. :-)\n" "\n" "KVM has returned -EFAULT since forever, i.e. it's effectively already part of the\n" @@ -78,4 +122,4 @@ "Well, yeah, but that's exactly why this series has a patch to reset exit_reason.\n" "The solution to \"if KVM is buggy then bad things happen\" is to not have KVM bugs :-)" -ff498d74836e4c2f4364da46ce6c2d5b3c96cd90256894fa3ec9d7434e9be118 +9e5f74d891b7b2df9311c70095ec4efafca3f3bb587fdec91a4559d57c15c109
diff --git a/a/1.txt b/N2/1.txt index 992a076..217e35c 100644 --- a/a/1.txt +++ b/N2/1.txt @@ -41,14 +41,14 @@ On Thu, Nov 02, 2023, Kai Huang wrote: > > reasons are preserved across KVM_RUN with vcpu->run->immediate_exit (or with a > > pending signal). > > -> > https://lore.kernel.org/all/ZFFbwOXZ5uI%2Fgdaf at google.com +> > https://lore.kernel.org/all/ZFFbwOXZ5uI%2Fgdaf@google.com > > > > > > Agreed with not to relax to any errno. However using -EFAULT as part of ABI > definition seems a little bit dangerous, e.g., someone could accidentally or > mistakenly return -EFAULT in KVM_RUN at early time and/or in a completely -> different code path, etc. ?-EINTR has well defined meaning, but -EFAULT (which +> different code path, etc. -EINTR has well defined meaning, but -EFAULT (which > is "Bad address") seems doesn't but I am not sure either. :-) KVM has returned -EFAULT since forever, i.e. it's effectively already part of the @@ -66,3 +66,8 @@ userspace to enable a capability *and* requires code in KVM to conditionally ret Well, yeah, but that's exactly why this series has a patch to reset exit_reason. The solution to "if KVM is buggy then bad things happen" is to not have KVM bugs :-) + +_______________________________________________ +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 dda4ef5..7b61aca 100644 --- a/a/content_digest +++ b/N2/content_digest @@ -4,9 +4,53 @@ "ref\0ZUKMsOdg3N9wmEzy@google.com\0" "ref\064e3764e36ba7a00d94cc7db1dea1ef06b620aaf.camel@intel.com\0" "From\0Sean Christopherson <seanjc@google.com>\0" - "Subject\0[PATCH v13 09/35] KVM: Add KVM_EXIT_MEMORY_FAULT exit to report faults to userspace\0" + "Subject\0Re: [PATCH v13 09/35] KVM: Add KVM_EXIT_MEMORY_FAULT exit to report faults to userspace\0" "Date\0Thu, 2 Nov 2023 08:56:43 -0700\0" - "To\0kvm-riscv@lists.infradead.org\0" + "To\0Kai Huang <kai.huang@intel.com>\0" + "Cc\0Xiaoyao Li <xiaoyao.li@intel.com>" + kvm-riscv@lists.infradead.org <kvm-riscv@lists.infradead.org> + mic@digikod.net <mic@digikod.net> + liam.merwick@oracle.com <liam.merwick@oracle.com> + Isaku Yamahata <isaku.yamahata@intel.com> + kvm@vger.kernel.org <kvm@vger.kernel.org> + pbonzini@redhat.com <pbonzini@redhat.com> + kirill.shutemov@linux.intel.com <kirill.shutemov@linux.intel.com> + david@redhat.com <david@redhat.com> + linux-fsdevel@vger.kernel.org <linux-fsdevel@vger.kernel.org> + amoorthy@google.com <amoorthy@google.com> + linuxppc-dev@lists.ozlabs.org <linuxppc-dev@lists.ozlabs.org> + tabba@google.com <tabba@google.com> + kvmarm@lists.linux.dev <kvmarm@lists.linux.dev> + linux-kernel@vger.kernel.org <linux-kernel@vger.kernel.org> + michael.roth@amd.com <michael.roth@amd.com> + viro@zeniv.linux.org.uk <viro@zeniv.linux.org.uk> + oliver.upton@linux.dev <oliver.upton@linux.dev> + chao.p.peng@linux.intel.com <chao.p.peng@linux.intel.com> + palmer@dabbelt.com <palmer@dabbelt.com> + chenhuacai@kernel.org <chenhuacai@kernel.org> + aou@eecs.berkeley.edu <aou@eecs.berkeley.edu> + linux-mips@vger.kernel.org <linux-mips@vger.kernel.org> + mpe@ellerman.id.au <mpe@ellerman.id.au> + Vishal Annapurve <vannapurve@google.com> + vbabka@suse.cz <vbabka@suse.cz> + mail@maciej.szmigiero.name <mail@maciej.szmigiero.name> + linux-riscv@lists.infradead.org <linux-riscv@lists.infradead.org> + maz@kernel.org <maz@kernel.org> + willy@infradead.org <willy@infradead.org> + dmatlack@google.com <dmatlack@google.com> + anup@brainfault.org <anup@brainfault.org> + yu.c.zhang@linux.intel.com <yu.c.zhang@linux.intel.com> + Yilun Xu <yilun.xu@intel.com> + qperret@google.com <qperret@google.com> + brauner@kernel.org <brauner@kernel.org> + isaku.yamahata@gmail.com <isaku.yamahata@gmail.com> + ackerleytng@google.com <ackerleytng@google.com> + jarkko@kernel.org <jarkko@kernel.org> + paul.walmsley@sifive.com <paul.walmsley@sifive.com> + linux-arm-kernel@lists.infradead.org <linux-arm-kernel@lists.infradead.org> + linux-mm@kvack.org <linux-mm@kvack.org> + Wei W Wang <wei.w.wang@intel.com> + " akpm@linux-foundation.org <akpm@linux-foundation.org>\0" "\00:1\0" "b\0" "On Thu, Nov 02, 2023, Kai Huang wrote:\n" @@ -52,14 +96,14 @@ "> > reasons are preserved across KVM_RUN with vcpu->run->immediate_exit (or with a\n" "> > pending signal).\n" "> > \n" - "> > https://lore.kernel.org/all/ZFFbwOXZ5uI%2Fgdaf at google.com\n" + "> > https://lore.kernel.org/all/ZFFbwOXZ5uI%2Fgdaf@google.com\n" "> > \n" "> > \n" "> \n" "> Agreed with not to relax to any errno. However using -EFAULT as part of ABI\n" "> definition seems a little bit dangerous, e.g., someone could accidentally or\n" "> mistakenly return -EFAULT in KVM_RUN at early time and/or in a completely\n" - "> different code path, etc. ?-EINTR has well defined meaning, but -EFAULT (which\n" + "> different code path, etc. \302\240-EINTR has well defined meaning, but -EFAULT (which\n" "> is \"Bad address\") seems doesn't but I am not sure either. :-)\n" "\n" "KVM has returned -EFAULT since forever, i.e. it's effectively already part of the\n" @@ -76,6 +120,11 @@ "> to have some issue here?\n" "\n" "Well, yeah, but that's exactly why this series has a patch to reset exit_reason.\n" - "The solution to \"if KVM is buggy then bad things happen\" is to not have KVM bugs :-)" + "The solution to \"if KVM is buggy then bad things happen\" is to not have KVM bugs :-)\n" + "\n" + "_______________________________________________\n" + "linux-riscv mailing list\n" + "linux-riscv@lists.infradead.org\n" + http://lists.infradead.org/mailman/listinfo/linux-riscv -ff498d74836e4c2f4364da46ce6c2d5b3c96cd90256894fa3ec9d7434e9be118 +68302e21b835d70bdd92c34656c31226c01954850fa536ff2e7a6ead7ff41e3c
diff --git a/a/1.txt b/N3/1.txt index 992a076..52955ec 100644 --- a/a/1.txt +++ b/N3/1.txt @@ -41,14 +41,14 @@ On Thu, Nov 02, 2023, Kai Huang wrote: > > reasons are preserved across KVM_RUN with vcpu->run->immediate_exit (or with a > > pending signal). > > -> > https://lore.kernel.org/all/ZFFbwOXZ5uI%2Fgdaf at google.com +> > https://lore.kernel.org/all/ZFFbwOXZ5uI%2Fgdaf@google.com > > > > > > Agreed with not to relax to any errno. However using -EFAULT as part of ABI > definition seems a little bit dangerous, e.g., someone could accidentally or > mistakenly return -EFAULT in KVM_RUN at early time and/or in a completely -> different code path, etc. ?-EINTR has well defined meaning, but -EFAULT (which +> different code path, etc. -EINTR has well defined meaning, but -EFAULT (which > is "Bad address") seems doesn't but I am not sure either. :-) KVM has returned -EFAULT since forever, i.e. it's effectively already part of the diff --git a/a/content_digest b/N3/content_digest index dda4ef5..d293282 100644 --- a/a/content_digest +++ b/N3/content_digest @@ -4,9 +4,52 @@ "ref\0ZUKMsOdg3N9wmEzy@google.com\0" "ref\064e3764e36ba7a00d94cc7db1dea1ef06b620aaf.camel@intel.com\0" "From\0Sean Christopherson <seanjc@google.com>\0" - "Subject\0[PATCH v13 09/35] KVM: Add KVM_EXIT_MEMORY_FAULT exit to report faults to userspace\0" + "Subject\0Re: [PATCH v13 09/35] KVM: Add KVM_EXIT_MEMORY_FAULT exit to report faults to userspace\0" "Date\0Thu, 2 Nov 2023 08:56:43 -0700\0" - "To\0kvm-riscv@lists.infradead.org\0" + "To\0Kai Huang <kai.huang@intel.com>\0" + "Cc\0kvm@vger.kernel.org <kvm@vger.kernel.org>" + david@redhat.com <david@redhat.com> + paul.walmsley@sifive.com <paul.walmsley@sifive.com> + linux-mips@vger.kernel.org <linux-mips@vger.kernel.org> + linux-mm@kvack.org <linux-mm@kvack.org> + mic@digikod.net <mic@digikod.net> + chao.p.peng@linux.intel.com <chao.p.peng@linux.intel.com> + linux-riscv@lists.infradead.org <linux-riscv@lists.infradead.org> + isaku.yamahata@gmail.com <isaku.yamahata@gmail.com> + chenhuacai@kernel.org <chenhuacai@kernel.org> + Xiaoyao Li <xiaoyao.li@intel.com> + willy@infradead.org <willy@infradead.org> + Wei W Wang <wei.w.wang@intel.com> + vbabka@suse.cz <vbabka@suse.cz> + yu.c.zhang@linux.intel.com <yu.c.zhang@linux.intel.com> + linux-arm-kernel@lists.infradead.org <linux-arm-kernel@lists.infradead.org> + mail@maciej.szmigiero.name <mail@maciej.szmigiero.name> + aou@eecs.berkeley.edu <aou@eecs.berkeley.edu> + michael.roth@amd.com <michael.roth@amd.com> + ackerleytng@google.com <ackerleytng@g oogle.com> + viro@zeniv.linux.org.uk <viro@zeniv.linux.org.uk> + liam.merwick@oracle.com <liam.merwick@oracle.com> + kvmarm@lists.linux.dev <kvmarm@lists.linux.dev> + tabba@google.com <tabba@google.com> + Isaku Yamahata <isaku.yamahata@intel.com> + brauner@kernel.org <brauner@kernel.org> + qperret@google.com <qperret@google.com> + anup@brainfault.org <anup@brainfault.org> + linux-kernel@vger.kernel.org <linux-kernel@vger.kernel.org> + oliver.upton@linux.dev <oliver.upton@linux.dev> + dmatlack@google.com <dmatlack@google.com> + jarkko@kernel.org <jarkko@kernel.org> + palmer@dabbelt.com <palmer@dabbelt.com> + kirill.shutemov@linux.intel.com <kirill.shutemov@linux.intel.com> + kvm-riscv@lists.infradead.org <kvm-riscv@lists.infradead.org> + maz@kernel.org <maz@kernel.org> + linux-fsdevel@vger.kernel.org <linux-fsdevel@vger.kernel.org> + pbonzini@redhat.com <pbonzini@redhat.com> + akpm@linux-foundation.org <akpm@linux-foundation.org> + Vishal Annapurve <vannapurve@google. com> + linuxppc-dev@lists.ozlabs.org <linuxppc-dev@lists.ozlabs.org> + Yilun Xu <yilun.xu@intel.com> + " amoorthy@google.com <amoorthy@google.com>\0" "\00:1\0" "b\0" "On Thu, Nov 02, 2023, Kai Huang wrote:\n" @@ -52,14 +95,14 @@ "> > reasons are preserved across KVM_RUN with vcpu->run->immediate_exit (or with a\n" "> > pending signal).\n" "> > \n" - "> > https://lore.kernel.org/all/ZFFbwOXZ5uI%2Fgdaf at google.com\n" + "> > https://lore.kernel.org/all/ZFFbwOXZ5uI%2Fgdaf@google.com\n" "> > \n" "> > \n" "> \n" "> Agreed with not to relax to any errno. However using -EFAULT as part of ABI\n" "> definition seems a little bit dangerous, e.g., someone could accidentally or\n" "> mistakenly return -EFAULT in KVM_RUN at early time and/or in a completely\n" - "> different code path, etc. ?-EINTR has well defined meaning, but -EFAULT (which\n" + "> different code path, etc. \302\240-EINTR has well defined meaning, but -EFAULT (which\n" "> is \"Bad address\") seems doesn't but I am not sure either. :-)\n" "\n" "KVM has returned -EFAULT since forever, i.e. it's effectively already part of the\n" @@ -78,4 +121,4 @@ "Well, yeah, but that's exactly why this series has a patch to reset exit_reason.\n" "The solution to \"if KVM is buggy then bad things happen\" is to not have KVM bugs :-)" -ff498d74836e4c2f4364da46ce6c2d5b3c96cd90256894fa3ec9d7434e9be118 +969b193fcac494a98b02e00a5592721816c959370833b194b31734917e5bba62
diff --git a/a/1.txt b/N4/1.txt index 992a076..200d36f 100644 --- a/a/1.txt +++ b/N4/1.txt @@ -41,14 +41,14 @@ On Thu, Nov 02, 2023, Kai Huang wrote: > > reasons are preserved across KVM_RUN with vcpu->run->immediate_exit (or with a > > pending signal). > > -> > https://lore.kernel.org/all/ZFFbwOXZ5uI%2Fgdaf at google.com +> > https://lore.kernel.org/all/ZFFbwOXZ5uI%2Fgdaf@google.com > > > > > > Agreed with not to relax to any errno. However using -EFAULT as part of ABI > definition seems a little bit dangerous, e.g., someone could accidentally or > mistakenly return -EFAULT in KVM_RUN at early time and/or in a completely -> different code path, etc. ?-EINTR has well defined meaning, but -EFAULT (which +> different code path, etc. -EINTR has well defined meaning, but -EFAULT (which > is "Bad address") seems doesn't but I am not sure either. :-) KVM has returned -EFAULT since forever, i.e. it's effectively already part of the @@ -66,3 +66,8 @@ userspace to enable a capability *and* requires code in KVM to conditionally ret Well, yeah, but that's exactly why this series has a patch to reset exit_reason. The solution to "if KVM is buggy then bad things happen" is to not have KVM bugs :-) + +_______________________________________________ +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 dda4ef5..65b28ce 100644 --- a/a/content_digest +++ b/N4/content_digest @@ -4,9 +4,53 @@ "ref\0ZUKMsOdg3N9wmEzy@google.com\0" "ref\064e3764e36ba7a00d94cc7db1dea1ef06b620aaf.camel@intel.com\0" "From\0Sean Christopherson <seanjc@google.com>\0" - "Subject\0[PATCH v13 09/35] KVM: Add KVM_EXIT_MEMORY_FAULT exit to report faults to userspace\0" + "Subject\0Re: [PATCH v13 09/35] KVM: Add KVM_EXIT_MEMORY_FAULT exit to report faults to userspace\0" "Date\0Thu, 2 Nov 2023 08:56:43 -0700\0" - "To\0kvm-riscv@lists.infradead.org\0" + "To\0Kai Huang <kai.huang@intel.com>\0" + "Cc\0Xiaoyao Li <xiaoyao.li@intel.com>" + kvm-riscv@lists.infradead.org <kvm-riscv@lists.infradead.org> + mic@digikod.net <mic@digikod.net> + liam.merwick@oracle.com <liam.merwick@oracle.com> + Isaku Yamahata <isaku.yamahata@intel.com> + kvm@vger.kernel.org <kvm@vger.kernel.org> + pbonzini@redhat.com <pbonzini@redhat.com> + kirill.shutemov@linux.intel.com <kirill.shutemov@linux.intel.com> + david@redhat.com <david@redhat.com> + linux-fsdevel@vger.kernel.org <linux-fsdevel@vger.kernel.org> + amoorthy@google.com <amoorthy@google.com> + linuxppc-dev@lists.ozlabs.org <linuxppc-dev@lists.ozlabs.org> + tabba@google.com <tabba@google.com> + kvmarm@lists.linux.dev <kvmarm@lists.linux.dev> + linux-kernel@vger.kernel.org <linux-kernel@vger.kernel.org> + michael.roth@amd.com <michael.roth@amd.com> + viro@zeniv.linux.org.uk <viro@zeniv.linux.org.uk> + oliver.upton@linux.dev <oliver.upton@linux.dev> + chao.p.peng@linux.intel.com <chao.p.peng@linux.intel.com> + palmer@dabbelt.com <palmer@dabbelt.com> + chenhuacai@kernel.org <chenhuacai@kernel.org> + aou@eecs.berkeley.edu <aou@eecs.berkeley.edu> + linux-mips@vger.kernel.org <linux-mips@vger.kernel.org> + mpe@ellerman.id.au <mpe@ellerman.id.au> + Vishal Annapurve <vannapurve@google.com> + vbabka@suse.cz <vbabka@suse.cz> + mail@maciej.szmigiero.name <mail@maciej.szmigiero.name> + linux-riscv@lists.infradead.org <linux-riscv@lists.infradead.org> + maz@kernel.org <maz@kernel.org> + willy@infradead.org <willy@infradead.org> + dmatlack@google.com <dmatlack@google.com> + anup@brainfault.org <anup@brainfault.org> + yu.c.zhang@linux.intel.com <yu.c.zhang@linux.intel.com> + Yilun Xu <yilun.xu@intel.com> + qperret@google.com <qperret@google.com> + brauner@kernel.org <brauner@kernel.org> + isaku.yamahata@gmail.com <isaku.yamahata@gmail.com> + ackerleytng@google.com <ackerleytng@google.com> + jarkko@kernel.org <jarkko@kernel.org> + paul.walmsley@sifive.com <paul.walmsley@sifive.com> + linux-arm-kernel@lists.infradead.org <linux-arm-kernel@lists.infradead.org> + linux-mm@kvack.org <linux-mm@kvack.org> + Wei W Wang <wei.w.wang@intel.com> + " akpm@linux-foundation.org <akpm@linux-foundation.org>\0" "\00:1\0" "b\0" "On Thu, Nov 02, 2023, Kai Huang wrote:\n" @@ -52,14 +96,14 @@ "> > reasons are preserved across KVM_RUN with vcpu->run->immediate_exit (or with a\n" "> > pending signal).\n" "> > \n" - "> > https://lore.kernel.org/all/ZFFbwOXZ5uI%2Fgdaf at google.com\n" + "> > https://lore.kernel.org/all/ZFFbwOXZ5uI%2Fgdaf@google.com\n" "> > \n" "> > \n" "> \n" "> Agreed with not to relax to any errno. However using -EFAULT as part of ABI\n" "> definition seems a little bit dangerous, e.g., someone could accidentally or\n" "> mistakenly return -EFAULT in KVM_RUN at early time and/or in a completely\n" - "> different code path, etc. ?-EINTR has well defined meaning, but -EFAULT (which\n" + "> different code path, etc. \302\240-EINTR has well defined meaning, but -EFAULT (which\n" "> is \"Bad address\") seems doesn't but I am not sure either. :-)\n" "\n" "KVM has returned -EFAULT since forever, i.e. it's effectively already part of the\n" @@ -76,6 +120,11 @@ "> to have some issue here?\n" "\n" "Well, yeah, but that's exactly why this series has a patch to reset exit_reason.\n" - "The solution to \"if KVM is buggy then bad things happen\" is to not have KVM bugs :-)" + "The solution to \"if KVM is buggy then bad things happen\" is to not have KVM bugs :-)\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 -ff498d74836e4c2f4364da46ce6c2d5b3c96cd90256894fa3ec9d7434e9be118 +349d93b3979e6184be202db7aabddf2a1abb2946b468c4d66d674e981c961ae2
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.