diff for duplicates of <Y4oh+XsbifA2BSj9@google.com> diff --git a/a/1.txt b/N1/1.txt index 100adb2..2b89fda 100644 --- a/a/1.txt +++ b/N1/1.txt @@ -3,17 +3,17 @@ On Fri, Dec 02, 2022, Huang, Kai wrote: > > --- a/arch/x86/kvm/x86.c > > +++ b/arch/x86/kvm/x86.c > > @@ -11967,6 +11967,11 @@ int kvm_arch_hardware_enable(void) -> > ? bool stable, backwards_tsc = false; -> > ? -> > ? kvm_user_return_msr_cpu_online(); +> > bool stable, backwards_tsc = false; +> > +> > kvm_user_return_msr_cpu_online(); > > + > > + ret = kvm_x86_check_processor_compatibility(); > > + if (ret) > > + return ret; > > + -> > ? ret = static_call(kvm_x86_hardware_enable)(); -> > ? if (ret != 0) -> > ? return ret; +> > ret = static_call(kvm_x86_hardware_enable)(); +> > if (ret != 0) +> > return ret; > > Thinking more, AFAICT, kvm_x86_vendor_init() so far still does the compatibility > check on all online cpus. Since now kvm_arch_hardware_enable() also does the @@ -34,3 +34,7 @@ to load and thus not instantiating /dev/kvm is friendlier to userspace, e.g. userspace can immediately flag the platform as potentially flaky, whereas detecting the likely hardware issue when VM creation fails would essentialy require scraping the kernel logs. +_______________________________________________ +kvmarm mailing list +kvmarm@lists.cs.columbia.edu +https://lists.cs.columbia.edu/mailman/listinfo/kvmarm diff --git a/a/content_digest b/N1/content_digest index 2efa2f9..7b0aa74 100644 --- a/a/content_digest +++ b/N1/content_digest @@ -2,9 +2,48 @@ "ref\020221130230934.1014142-41-seanjc@google.com\0" "ref\0cf755389c21c73e8367d8162cabc83629d3f9a74.camel@intel.com\0" "From\0Sean Christopherson <seanjc@google.com>\0" - "Subject\0[PATCH v2 40/50] KVM: x86: Do compatibility checks when onlining CPU\0" + "Subject\0Re: [PATCH v2 40/50] KVM: x86: Do compatibility checks when onlining CPU\0" "Date\0Fri, 2 Dec 2022 16:04:09 +0000\0" - "To\0kvm-riscv@lists.infradead.org\0" + "To\0Huang" + " Kai <kai.huang@intel.com>\0" + "Cc\0mjrosato@linux.ibm.com <mjrosato@linux.ibm.com>" + paul@xen.org <paul@xen.org> + Yao + Yuan <yuan.yao@intel.com> + david@redhat.com <david@redhat.com> + linux-mips@vger.kernel.org <linux-mips@vger.kernel.org> + atishp@atishpatra.org <atishp@atishpatra.org> + mpe@ellerman.id.au <mpe@ellerman.id.au> + linux-riscv@lists.infradead.org <linux-riscv@lists.infradead.org> + imbrenda@linux.ibm.com <imbrenda@linux.ibm.com> + kvmarm@lists.cs.columbia.edu <kvmarm@lists.cs.columbia.edu> + linux-s390@vger.kernel.org <linux-s390@vger.kernel.org> + frankja@linux.ibm.com <frankja@linux.ibm.com> + maz@kernel.org <maz@kernel.org> + chenhuacai@kernel.org <chenhuacai@kernel.org> + aleksandar.qemu.devel@gmail.com <aleksandar.qemu.devel@gmail.com> + borntraeger@linux.ibm.com <borntraeger@linux.ibm.com> + Gao + Chao <chao.gao@intel.com> + farman@linux.ibm.com <farman@linux.ibm.com> + aou@eecs.berkeley.edu <aou@eecs.berkeley.edu> + kvm@vger.kernel.org <kvm@vger.kernel.org> + paul.walmsley@sifive.com <paul.walmsley@sifive.com> + kvmarm@lists.linux.dev <kvmarm@lists.linux.dev> + tglx@linutronix.de <tglx@linutronix.de> + linux-arm-kernel@lists.infradead.org <linux-arm-kernel@lists.infradead.org> + Yamahata + Isaku <isaku.yamahata@intel.com> + philmd@linaro.org <philmd@linaro.org> + farosas@linux.ibm.com <farosas@linux.ibm.com> + linuxppc-dev@lists.ozlabs.org <linuxppc-dev@lists.ozlabs.org> + cohuck@redhat.com <cohuck@redhat.com> + linux-kernel@vger.kernel.org <linux-kernel@vger.kernel.org> + palmer@dabbelt.com <palmer@dabbelt.com> + kvm-riscv@lists.infradead.org <kvm-riscv@lists.infradead.org> + pbonzini@redhat.com <pbonzini@redhat.com> + vkuznets@redhat.com <vkuznets@redhat.com> + " dwmw2@infradead.org <dwmw2@infradead.org>\0" "\00:1\0" "b\0" "On Fri, Dec 02, 2022, Huang, Kai wrote:\n" @@ -12,17 +51,17 @@ "> > --- a/arch/x86/kvm/x86.c\n" "> > +++ b/arch/x86/kvm/x86.c\n" "> > @@ -11967,6 +11967,11 @@ int kvm_arch_hardware_enable(void)\n" - "> > ?\tbool stable, backwards_tsc = false;\n" - "> > ?\n" - "> > ?\tkvm_user_return_msr_cpu_online();\n" + "> > \302\240\tbool stable, backwards_tsc = false;\n" + "> > \302\240\n" + "> > \302\240\tkvm_user_return_msr_cpu_online();\n" "> > +\n" "> > +\tret = kvm_x86_check_processor_compatibility();\n" "> > +\tif (ret)\n" "> > +\t\treturn ret;\n" "> > +\n" - "> > ?\tret = static_call(kvm_x86_hardware_enable)();\n" - "> > ?\tif (ret != 0)\n" - "> > ?\t\treturn ret;\n" + "> > \302\240\tret = static_call(kvm_x86_hardware_enable)();\n" + "> > \302\240\tif (ret != 0)\n" + "> > \302\240\t\treturn ret;\n" "> \n" "> Thinking more, AFAICT, kvm_x86_vendor_init() so far still does the compatibility\n" "> check on all online cpus. Since now kvm_arch_hardware_enable() also does the\n" @@ -42,6 +81,10 @@ "to load and thus not instantiating /dev/kvm is friendlier to userspace, e.g.\n" "userspace can immediately flag the platform as potentially flaky, whereas\n" "detecting the likely hardware issue when VM creation fails would essentialy require\n" - scraping the kernel logs. + "scraping the kernel logs.\n" + "_______________________________________________\n" + "kvmarm mailing list\n" + "kvmarm@lists.cs.columbia.edu\n" + https://lists.cs.columbia.edu/mailman/listinfo/kvmarm -db98bcee9edae1e81d5b80122781b64bbbfd5d4129d84faca7028dd2f50d9b68 +b8352ead0c7861fd4a9d9446c6eb7917f173b7abcb8238e5abaf4c32e5424c63
diff --git a/a/1.txt b/N2/1.txt index 100adb2..e46e297 100644 --- a/a/1.txt +++ b/N2/1.txt @@ -3,17 +3,17 @@ On Fri, Dec 02, 2022, Huang, Kai wrote: > > --- a/arch/x86/kvm/x86.c > > +++ b/arch/x86/kvm/x86.c > > @@ -11967,6 +11967,11 @@ int kvm_arch_hardware_enable(void) -> > ? bool stable, backwards_tsc = false; -> > ? -> > ? kvm_user_return_msr_cpu_online(); +> > bool stable, backwards_tsc = false; +> > +> > kvm_user_return_msr_cpu_online(); > > + > > + ret = kvm_x86_check_processor_compatibility(); > > + if (ret) > > + return ret; > > + -> > ? ret = static_call(kvm_x86_hardware_enable)(); -> > ? if (ret != 0) -> > ? return ret; +> > ret = static_call(kvm_x86_hardware_enable)(); +> > if (ret != 0) +> > return ret; > > Thinking more, AFAICT, kvm_x86_vendor_init() so far still does the compatibility > check on all online cpus. Since now kvm_arch_hardware_enable() also does the diff --git a/a/content_digest b/N2/content_digest index 2efa2f9..75cfb30 100644 --- a/a/content_digest +++ b/N2/content_digest @@ -2,9 +2,53 @@ "ref\020221130230934.1014142-41-seanjc@google.com\0" "ref\0cf755389c21c73e8367d8162cabc83629d3f9a74.camel@intel.com\0" "From\0Sean Christopherson <seanjc@google.com>\0" - "Subject\0[PATCH v2 40/50] KVM: x86: Do compatibility checks when onlining CPU\0" + "Subject\0Re: [PATCH v2 40/50] KVM: x86: Do compatibility checks when onlining CPU\0" "Date\0Fri, 2 Dec 2022 16:04:09 +0000\0" - "To\0kvm-riscv@lists.infradead.org\0" + "To\0Huang" + " Kai <kai.huang@intel.com>\0" + "Cc\0chenhuacai@kernel.org <chenhuacai@kernel.org>" + maz@kernel.org <maz@kernel.org> + frankja@linux.ibm.com <frankja@linux.ibm.com> + borntraeger@linux.ibm.com <borntraeger@linux.ibm.com> + farman@linux.ibm.com <farman@linux.ibm.com> + aou@eecs.berkeley.edu <aou@eecs.berkeley.edu> + palmer@dabbelt.com <palmer@dabbelt.com> + paul.walmsley@sifive.com <paul.walmsley@sifive.com> + pbonzini@redhat.com <pbonzini@redhat.com> + dwmw2@infradead.org <dwmw2@infradead.org> + aleksandar.qemu.devel@gmail.com <aleksandar.qemu.devel@gmail.com> + imbrenda@linux.ibm.com <imbrenda@linux.ibm.com> + paul@xen.org <paul@xen.org> + mjrosato@linux.ibm.com <mjrosato@linux.ibm.com> + vkuznets@redhat.com <vkuznets@redhat.com> + anup@brainfault.org <anup@brainfault.org> + oliver.upton@linux.dev <oliver.upton@linux.dev> + kvm@vger.kernel.org <kvm@vger.kernel.org> + cohuck@redhat.com <cohuck@redhat.com> + farosas@linux.ibm.com <farosas@linux.ibm.com> + david@redhat.com <david@redhat.com> + james.morse@arm.com <james.morse@arm.com> + Yao + Yuan <yuan.yao@intel.com> + alexandru.elisei@arm.com <alexandru.elisei@arm.com> + linux-s390@vger.kernel.org <linux-s390@vger.kernel.org> + linux-kernel@vger.kernel.org <linux-kernel@vger.kernel.org> + mpe@ellerman.id.au <mpe@ellerman.id.au> + Yamahata + Isaku <isaku.yamahata@intel.com> + kvmarm@lists.linux.dev <kvmarm@lists.linux.dev> + tglx@linutronix.de <tglx@linutronix.de> + suzuki.poulose@arm.com <suzuki.poulose@arm.com> + kvm-riscv@lists.infradead.org <kvm-riscv@lists.infradead.org> + linuxppc-dev@lists.ozlabs.org <linuxppc-dev@lists.ozlabs.org> + linux-arm-kernel@lists.infradead.org <linux-arm-kernel@lists.infradead.org> + linux-mips@vger.kernel.org <linux-mips@vger.kernel.org> + kvmarm@lists.cs.columbia.edu <kvmarm@lists.cs.columbia.edu> + philmd@linaro.org <philmd@linaro.org> + atishp@atishpatra.org <atishp@atishpatra.org> + linux-riscv@lists.infradead.org <linux-riscv@lists.infradead.org> + Gao + " Chao <chao.gao@intel.com>\0" "\00:1\0" "b\0" "On Fri, Dec 02, 2022, Huang, Kai wrote:\n" @@ -12,17 +56,17 @@ "> > --- a/arch/x86/kvm/x86.c\n" "> > +++ b/arch/x86/kvm/x86.c\n" "> > @@ -11967,6 +11967,11 @@ int kvm_arch_hardware_enable(void)\n" - "> > ?\tbool stable, backwards_tsc = false;\n" - "> > ?\n" - "> > ?\tkvm_user_return_msr_cpu_online();\n" + "> > \302\240\tbool stable, backwards_tsc = false;\n" + "> > \302\240\n" + "> > \302\240\tkvm_user_return_msr_cpu_online();\n" "> > +\n" "> > +\tret = kvm_x86_check_processor_compatibility();\n" "> > +\tif (ret)\n" "> > +\t\treturn ret;\n" "> > +\n" - "> > ?\tret = static_call(kvm_x86_hardware_enable)();\n" - "> > ?\tif (ret != 0)\n" - "> > ?\t\treturn ret;\n" + "> > \302\240\tret = static_call(kvm_x86_hardware_enable)();\n" + "> > \302\240\tif (ret != 0)\n" + "> > \302\240\t\treturn ret;\n" "> \n" "> Thinking more, AFAICT, kvm_x86_vendor_init() so far still does the compatibility\n" "> check on all online cpus. Since now kvm_arch_hardware_enable() also does the\n" @@ -44,4 +88,4 @@ "detecting the likely hardware issue when VM creation fails would essentialy require\n" scraping the kernel logs. -db98bcee9edae1e81d5b80122781b64bbbfd5d4129d84faca7028dd2f50d9b68 +9fc1df5643b65c7f7e457871e6c184e1e61d7a2d4bd959ac619eea69b2a8c722
diff --git a/a/1.txt b/N3/1.txt index 100adb2..d1ad7be 100644 --- a/a/1.txt +++ b/N3/1.txt @@ -3,17 +3,17 @@ On Fri, Dec 02, 2022, Huang, Kai wrote: > > --- a/arch/x86/kvm/x86.c > > +++ b/arch/x86/kvm/x86.c > > @@ -11967,6 +11967,11 @@ int kvm_arch_hardware_enable(void) -> > ? bool stable, backwards_tsc = false; -> > ? -> > ? kvm_user_return_msr_cpu_online(); +> > bool stable, backwards_tsc = false; +> > +> > kvm_user_return_msr_cpu_online(); > > + > > + ret = kvm_x86_check_processor_compatibility(); > > + if (ret) > > + return ret; > > + -> > ? ret = static_call(kvm_x86_hardware_enable)(); -> > ? if (ret != 0) -> > ? return ret; +> > ret = static_call(kvm_x86_hardware_enable)(); +> > if (ret != 0) +> > return ret; > > Thinking more, AFAICT, kvm_x86_vendor_init() so far still does the compatibility > check on all online cpus. Since now kvm_arch_hardware_enable() also does the @@ -34,3 +34,8 @@ to load and thus not instantiating /dev/kvm is friendlier to userspace, e.g. userspace can immediately flag the platform as potentially flaky, whereas detecting the likely hardware issue when VM creation fails would essentialy require scraping the kernel logs. + +_______________________________________________ +linux-riscv mailing list +linux-riscv@lists.infradead.org +http://lists.infradead.org/mailman/listinfo/linux-riscv diff --git a/a/content_digest b/N3/content_digest index 2efa2f9..aebe80b 100644 --- a/a/content_digest +++ b/N3/content_digest @@ -2,9 +2,53 @@ "ref\020221130230934.1014142-41-seanjc@google.com\0" "ref\0cf755389c21c73e8367d8162cabc83629d3f9a74.camel@intel.com\0" "From\0Sean Christopherson <seanjc@google.com>\0" - "Subject\0[PATCH v2 40/50] KVM: x86: Do compatibility checks when onlining CPU\0" + "Subject\0Re: [PATCH v2 40/50] KVM: x86: Do compatibility checks when onlining CPU\0" "Date\0Fri, 2 Dec 2022 16:04:09 +0000\0" - "To\0kvm-riscv@lists.infradead.org\0" + "To\0Huang" + " Kai <kai.huang@intel.com>\0" + "Cc\0chenhuacai@kernel.org <chenhuacai@kernel.org>" + maz@kernel.org <maz@kernel.org> + frankja@linux.ibm.com <frankja@linux.ibm.com> + borntraeger@linux.ibm.com <borntraeger@linux.ibm.com> + farman@linux.ibm.com <farman@linux.ibm.com> + aou@eecs.berkeley.edu <aou@eecs.berkeley.edu> + palmer@dabbelt.com <palmer@dabbelt.com> + paul.walmsley@sifive.com <paul.walmsley@sifive.com> + pbonzini@redhat.com <pbonzini@redhat.com> + dwmw2@infradead.org <dwmw2@infradead.org> + aleksandar.qemu.devel@gmail.com <aleksandar.qemu.devel@gmail.com> + imbrenda@linux.ibm.com <imbrenda@linux.ibm.com> + paul@xen.org <paul@xen.org> + mjrosato@linux.ibm.com <mjrosato@linux.ibm.com> + vkuznets@redhat.com <vkuznets@redhat.com> + anup@brainfault.org <anup@brainfault.org> + oliver.upton@linux.dev <oliver.upton@linux.dev> + kvm@vger.kernel.org <kvm@vger.kernel.org> + cohuck@redhat.com <cohuck@redhat.com> + farosas@linux.ibm.com <farosas@linux.ibm.com> + david@redhat.com <david@redhat.com> + james.morse@arm.com <james.morse@arm.com> + Yao + Yuan <yuan.yao@intel.com> + alexandru.elisei@arm.com <alexandru.elisei@arm.com> + linux-s390@vger.kernel.org <linux-s390@vger.kernel.org> + linux-kernel@vger.kernel.org <linux-kernel@vger.kernel.org> + mpe@ellerman.id.au <mpe@ellerman.id.au> + Yamahata + Isaku <isaku.yamahata@intel.com> + kvmarm@lists.linux.dev <kvmarm@lists.linux.dev> + tglx@linutronix.de <tglx@linutronix.de> + suzuki.poulose@arm.com <suzuki.poulose@arm.com> + kvm-riscv@lists.infradead.org <kvm-riscv@lists.infradead.org> + linuxppc-dev@lists.ozlabs.org <linuxppc-dev@lists.ozlabs.org> + linux-arm-kernel@lists.infradead.org <linux-arm-kernel@lists.infradead.org> + linux-mips@vger.kernel.org <linux-mips@vger.kernel.org> + kvmarm@lists.cs.columbia.edu <kvmarm@lists.cs.columbia.edu> + philmd@linaro.org <philmd@linaro.org> + atishp@atishpatra.org <atishp@atishpatra.org> + linux-riscv@lists.infradead.org <linux-riscv@lists.infradead.org> + Gao + " Chao <chao.gao@intel.com>\0" "\00:1\0" "b\0" "On Fri, Dec 02, 2022, Huang, Kai wrote:\n" @@ -12,17 +56,17 @@ "> > --- a/arch/x86/kvm/x86.c\n" "> > +++ b/arch/x86/kvm/x86.c\n" "> > @@ -11967,6 +11967,11 @@ int kvm_arch_hardware_enable(void)\n" - "> > ?\tbool stable, backwards_tsc = false;\n" - "> > ?\n" - "> > ?\tkvm_user_return_msr_cpu_online();\n" + "> > \302\240\tbool stable, backwards_tsc = false;\n" + "> > \302\240\n" + "> > \302\240\tkvm_user_return_msr_cpu_online();\n" "> > +\n" "> > +\tret = kvm_x86_check_processor_compatibility();\n" "> > +\tif (ret)\n" "> > +\t\treturn ret;\n" "> > +\n" - "> > ?\tret = static_call(kvm_x86_hardware_enable)();\n" - "> > ?\tif (ret != 0)\n" - "> > ?\t\treturn ret;\n" + "> > \302\240\tret = static_call(kvm_x86_hardware_enable)();\n" + "> > \302\240\tif (ret != 0)\n" + "> > \302\240\t\treturn ret;\n" "> \n" "> Thinking more, AFAICT, kvm_x86_vendor_init() so far still does the compatibility\n" "> check on all online cpus. Since now kvm_arch_hardware_enable() also does the\n" @@ -42,6 +86,11 @@ "to load and thus not instantiating /dev/kvm is friendlier to userspace, e.g.\n" "userspace can immediately flag the platform as potentially flaky, whereas\n" "detecting the likely hardware issue when VM creation fails would essentialy require\n" - scraping the kernel logs. + "scraping the kernel logs.\n" + "\n" + "_______________________________________________\n" + "linux-riscv mailing list\n" + "linux-riscv@lists.infradead.org\n" + http://lists.infradead.org/mailman/listinfo/linux-riscv -db98bcee9edae1e81d5b80122781b64bbbfd5d4129d84faca7028dd2f50d9b68 +abadf961e043576ff18270ac94d61bd07de7e868abb004ab159e3324c8512784
diff --git a/a/1.txt b/N4/1.txt index 100adb2..e46e297 100644 --- a/a/1.txt +++ b/N4/1.txt @@ -3,17 +3,17 @@ On Fri, Dec 02, 2022, Huang, Kai wrote: > > --- a/arch/x86/kvm/x86.c > > +++ b/arch/x86/kvm/x86.c > > @@ -11967,6 +11967,11 @@ int kvm_arch_hardware_enable(void) -> > ? bool stable, backwards_tsc = false; -> > ? -> > ? kvm_user_return_msr_cpu_online(); +> > bool stable, backwards_tsc = false; +> > +> > kvm_user_return_msr_cpu_online(); > > + > > + ret = kvm_x86_check_processor_compatibility(); > > + if (ret) > > + return ret; > > + -> > ? ret = static_call(kvm_x86_hardware_enable)(); -> > ? if (ret != 0) -> > ? return ret; +> > ret = static_call(kvm_x86_hardware_enable)(); +> > if (ret != 0) +> > return ret; > > Thinking more, AFAICT, kvm_x86_vendor_init() so far still does the compatibility > check on all online cpus. Since now kvm_arch_hardware_enable() also does the diff --git a/a/content_digest b/N4/content_digest index 2efa2f9..fe957c2 100644 --- a/a/content_digest +++ b/N4/content_digest @@ -2,9 +2,52 @@ "ref\020221130230934.1014142-41-seanjc@google.com\0" "ref\0cf755389c21c73e8367d8162cabc83629d3f9a74.camel@intel.com\0" "From\0Sean Christopherson <seanjc@google.com>\0" - "Subject\0[PATCH v2 40/50] KVM: x86: Do compatibility checks when onlining CPU\0" + "Subject\0Re: [PATCH v2 40/50] KVM: x86: Do compatibility checks when onlining CPU\0" "Date\0Fri, 2 Dec 2022 16:04:09 +0000\0" - "To\0kvm-riscv@lists.infradead.org\0" + "To\0Huang" + " Kai <kai.huang@intel.com>\0" + "Cc\0mjrosato@linux.ibm.com <mjrosato@linux.ibm.com>" + paul@xen.org <paul@xen.org> + Yao + Yuan <yuan.yao@intel.com> + david@redhat.com <david@redhat.com> + linux-mips@vger.kernel.org <linux-mips@vger.kernel.org> + atishp@atishpatra.org <atishp@atishpatra.org> + linux-riscv@lists.infradead.org <linux-riscv@lists.infradead.org> + imbrenda@linux.ibm.com <imbrenda@linux.ibm.com> + kvmarm@lists.cs.columbia.edu <kvmarm@lists.cs.columbia.edu> + linux-s390@vger.kernel.org <linux-s390@vger.kernel.org> + frankja@linux.ibm.com <frankja@linux.ibm.com> + maz@kernel.org <maz@kernel.org> + chenhuacai@kernel.org <chenhuacai@kernel.org> + aleksandar.qemu.devel@gmail.com <aleksandar.qemu.devel@gmail.com> + james.morse@arm.com <james.morse@arm.com> + borntraeger@linux.ibm.com <borntraeger@linux.ibm.com> + Gao + Chao <chao.gao@intel.com> + farman@linux.ibm.com <farman@linux.ibm.com> + aou@eecs.berkeley.edu <aou@eecs.berkeley.edu> + suzuki.poulose@arm.com <suzuki.poulose@arm.com> + kvm @vger.kernel.org <kvm@vger.kernel.org> + paul.walmsley@sifive.com <paul.walmsley@sifive.com> + kvmarm@lists.linux.dev <kvmarm@lists.linux.dev> + tglx@linutronix.de <tglx@linutronix.de> + alexandru.elisei@arm.com <alexandru.elisei@arm.com> + linux-arm-kernel@lists.infradead.org <linux-arm-kernel@lists.infradead.org> + Yamahata + Isaku <isaku.yamahata@intel.com> + philmd@linaro.org <philmd@linaro.org> + farosas@linux.ibm.com <farosas@linux.ibm.com> + linuxppc-dev@lists.ozlabs.org <linuxppc-dev@lists.ozlabs.org> + cohuck@redhat.com <cohuck@redhat.com> + linux-kernel@vger.kernel.org <linux-kernel@vger.kernel.org> + oliver.upton@linux.dev <oliver.upton@linux.dev> + palmer@dabbelt.com <palmer@dabbelt.com> + kvm-riscv@lists.infradead.org <kvm-riscv@lists.infradead.org> + anup@brainfault.org <anup@brainfault.org> + pbonzini@redhat.com <pbonzini@redhat.com> + vkuznets@redhat.com <vkuznets@redhat.com> + " dwmw2@infradead.org <dwmw2@infradead.org>\0" "\00:1\0" "b\0" "On Fri, Dec 02, 2022, Huang, Kai wrote:\n" @@ -12,17 +55,17 @@ "> > --- a/arch/x86/kvm/x86.c\n" "> > +++ b/arch/x86/kvm/x86.c\n" "> > @@ -11967,6 +11967,11 @@ int kvm_arch_hardware_enable(void)\n" - "> > ?\tbool stable, backwards_tsc = false;\n" - "> > ?\n" - "> > ?\tkvm_user_return_msr_cpu_online();\n" + "> > \302\240\tbool stable, backwards_tsc = false;\n" + "> > \302\240\n" + "> > \302\240\tkvm_user_return_msr_cpu_online();\n" "> > +\n" "> > +\tret = kvm_x86_check_processor_compatibility();\n" "> > +\tif (ret)\n" "> > +\t\treturn ret;\n" "> > +\n" - "> > ?\tret = static_call(kvm_x86_hardware_enable)();\n" - "> > ?\tif (ret != 0)\n" - "> > ?\t\treturn ret;\n" + "> > \302\240\tret = static_call(kvm_x86_hardware_enable)();\n" + "> > \302\240\tif (ret != 0)\n" + "> > \302\240\t\treturn ret;\n" "> \n" "> Thinking more, AFAICT, kvm_x86_vendor_init() so far still does the compatibility\n" "> check on all online cpus. Since now kvm_arch_hardware_enable() also does the\n" @@ -44,4 +87,4 @@ "detecting the likely hardware issue when VM creation fails would essentialy require\n" scraping the kernel logs. -db98bcee9edae1e81d5b80122781b64bbbfd5d4129d84faca7028dd2f50d9b68 +1850c3bdc2545d2c1075f0a34a601141dc1736344120933a54de3af111123e8b
diff --git a/a/1.txt b/N5/1.txt index 100adb2..9ec92a4 100644 --- a/a/1.txt +++ b/N5/1.txt @@ -3,17 +3,17 @@ On Fri, Dec 02, 2022, Huang, Kai wrote: > > --- a/arch/x86/kvm/x86.c > > +++ b/arch/x86/kvm/x86.c > > @@ -11967,6 +11967,11 @@ int kvm_arch_hardware_enable(void) -> > ? bool stable, backwards_tsc = false; -> > ? -> > ? kvm_user_return_msr_cpu_online(); +> > bool stable, backwards_tsc = false; +> > +> > kvm_user_return_msr_cpu_online(); > > + > > + ret = kvm_x86_check_processor_compatibility(); > > + if (ret) > > + return ret; > > + -> > ? ret = static_call(kvm_x86_hardware_enable)(); -> > ? if (ret != 0) -> > ? return ret; +> > ret = static_call(kvm_x86_hardware_enable)(); +> > if (ret != 0) +> > return ret; > > Thinking more, AFAICT, kvm_x86_vendor_init() so far still does the compatibility > check on all online cpus. Since now kvm_arch_hardware_enable() also does the @@ -34,3 +34,8 @@ to load and thus not instantiating /dev/kvm is friendlier to userspace, e.g. userspace can immediately flag the platform as potentially flaky, whereas detecting the likely hardware issue when VM creation fails would essentialy require scraping the kernel logs. + +_______________________________________________ +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/N5/content_digest index 2efa2f9..5e8e478 100644 --- a/a/content_digest +++ b/N5/content_digest @@ -2,9 +2,53 @@ "ref\020221130230934.1014142-41-seanjc@google.com\0" "ref\0cf755389c21c73e8367d8162cabc83629d3f9a74.camel@intel.com\0" "From\0Sean Christopherson <seanjc@google.com>\0" - "Subject\0[PATCH v2 40/50] KVM: x86: Do compatibility checks when onlining CPU\0" + "Subject\0Re: [PATCH v2 40/50] KVM: x86: Do compatibility checks when onlining CPU\0" "Date\0Fri, 2 Dec 2022 16:04:09 +0000\0" - "To\0kvm-riscv@lists.infradead.org\0" + "To\0Huang" + " Kai <kai.huang@intel.com>\0" + "Cc\0chenhuacai@kernel.org <chenhuacai@kernel.org>" + maz@kernel.org <maz@kernel.org> + frankja@linux.ibm.com <frankja@linux.ibm.com> + borntraeger@linux.ibm.com <borntraeger@linux.ibm.com> + farman@linux.ibm.com <farman@linux.ibm.com> + aou@eecs.berkeley.edu <aou@eecs.berkeley.edu> + palmer@dabbelt.com <palmer@dabbelt.com> + paul.walmsley@sifive.com <paul.walmsley@sifive.com> + pbonzini@redhat.com <pbonzini@redhat.com> + dwmw2@infradead.org <dwmw2@infradead.org> + aleksandar.qemu.devel@gmail.com <aleksandar.qemu.devel@gmail.com> + imbrenda@linux.ibm.com <imbrenda@linux.ibm.com> + paul@xen.org <paul@xen.org> + mjrosato@linux.ibm.com <mjrosato@linux.ibm.com> + vkuznets@redhat.com <vkuznets@redhat.com> + anup@brainfault.org <anup@brainfault.org> + oliver.upton@linux.dev <oliver.upton@linux.dev> + kvm@vger.kernel.org <kvm@vger.kernel.org> + cohuck@redhat.com <cohuck@redhat.com> + farosas@linux.ibm.com <farosas@linux.ibm.com> + david@redhat.com <david@redhat.com> + james.morse@arm.com <james.morse@arm.com> + Yao + Yuan <yuan.yao@intel.com> + alexandru.elisei@arm.com <alexandru.elisei@arm.com> + linux-s390@vger.kernel.org <linux-s390@vger.kernel.org> + linux-kernel@vger.kernel.org <linux-kernel@vger.kernel.org> + mpe@ellerman.id.au <mpe@ellerman.id.au> + Yamahata + Isaku <isaku.yamahata@intel.com> + kvmarm@lists.linux.dev <kvmarm@lists.linux.dev> + tglx@linutronix.de <tglx@linutronix.de> + suzuki.poulose@arm.com <suzuki.poulose@arm.com> + kvm-riscv@lists.infradead.org <kvm-riscv@lists.infradead.org> + linuxppc-dev@lists.ozlabs.org <linuxppc-dev@lists.ozlabs.org> + linux-arm-kernel@lists.infradead.org <linux-arm-kernel@lists.infradead.org> + linux-mips@vger.kernel.org <linux-mips@vger.kernel.org> + kvmarm@lists.cs.columbia.edu <kvmarm@lists.cs.columbia.edu> + philmd@linaro.org <philmd@linaro.org> + atishp@atishpatra.org <atishp@atishpatra.org> + linux-riscv@lists.infradead.org <linux-riscv@lists.infradead.org> + Gao + " Chao <chao.gao@intel.com>\0" "\00:1\0" "b\0" "On Fri, Dec 02, 2022, Huang, Kai wrote:\n" @@ -12,17 +56,17 @@ "> > --- a/arch/x86/kvm/x86.c\n" "> > +++ b/arch/x86/kvm/x86.c\n" "> > @@ -11967,6 +11967,11 @@ int kvm_arch_hardware_enable(void)\n" - "> > ?\tbool stable, backwards_tsc = false;\n" - "> > ?\n" - "> > ?\tkvm_user_return_msr_cpu_online();\n" + "> > \302\240\tbool stable, backwards_tsc = false;\n" + "> > \302\240\n" + "> > \302\240\tkvm_user_return_msr_cpu_online();\n" "> > +\n" "> > +\tret = kvm_x86_check_processor_compatibility();\n" "> > +\tif (ret)\n" "> > +\t\treturn ret;\n" "> > +\n" - "> > ?\tret = static_call(kvm_x86_hardware_enable)();\n" - "> > ?\tif (ret != 0)\n" - "> > ?\t\treturn ret;\n" + "> > \302\240\tret = static_call(kvm_x86_hardware_enable)();\n" + "> > \302\240\tif (ret != 0)\n" + "> > \302\240\t\treturn ret;\n" "> \n" "> Thinking more, AFAICT, kvm_x86_vendor_init() so far still does the compatibility\n" "> check on all online cpus. Since now kvm_arch_hardware_enable() also does the\n" @@ -42,6 +86,11 @@ "to load and thus not instantiating /dev/kvm is friendlier to userspace, e.g.\n" "userspace can immediately flag the platform as potentially flaky, whereas\n" "detecting the likely hardware issue when VM creation fails would essentialy require\n" - scraping the kernel logs. + "scraping the kernel logs.\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 -db98bcee9edae1e81d5b80122781b64bbbfd5d4129d84faca7028dd2f50d9b68 +34126078b17575bce925f3b899d3c52ec420795dbe3f88baab2f16a5cda3853c
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.