From mboxrd@z Thu Jan 1 00:00:00 1970 From: Sean Christopherson Date: Fri, 2 Dec 2022 16:04:09 +0000 Subject: [PATCH v2 40/50] KVM: x86: Do compatibility checks when onlining CPU In-Reply-To: References: <20221130230934.1014142-1-seanjc@google.com> <20221130230934.1014142-41-seanjc@google.com> Message-ID: List-Id: To: kvm-riscv@lists.infradead.org MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit On Fri, Dec 02, 2022, Huang, Kai wrote: > On Wed, 2022-11-30 at 23:09 +0000, Sean Christopherson 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(); > > + > > + ret = kvm_x86_check_processor_compatibility(); > > + if (ret) > > + 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 > compatibility check, IIUC the compatibility check will be done twice -- one in > kvm_x86_vendor_init() and one in hardware_enable_all() when creating the first > VM. > > Do you think it's still worth to do compatibility check in vm_x86_vendor_init()? > > The behaviour difference should be "KVM module fail to load" vs "failing to > create the first VM" IIUC. I don't know whether the former is better than the > better, but it seems duplicated compatibility checking isn't needed? It's not strictly needed, but I think it's worth keeping. The duplicate checking annoys me too, and I considered removing it multiple times when creating this series. But, if there is a hardware incompatibility for whatever reason, failing 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. From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from mm01.cs.columbia.edu (mm01.cs.columbia.edu [128.59.11.253]) by smtp.lore.kernel.org (Postfix) with ESMTP id 09B31C4321E for ; Fri, 2 Dec 2022 16:04:22 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by mm01.cs.columbia.edu (Postfix) with ESMTP id 89CCC4120D; Fri, 2 Dec 2022 11:04:22 -0500 (EST) X-Virus-Scanned: at lists.cs.columbia.edu Authentication-Results: mm01.cs.columbia.edu (amavisd-new); dkim=softfail (fail, message has been altered) header.i=@google.com Received: from mm01.cs.columbia.edu ([127.0.0.1]) by localhost (mm01.cs.columbia.edu [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id s9mai4bjLS85; Fri, 2 Dec 2022 11:04:21 -0500 (EST) Received: from mm01.cs.columbia.edu (localhost [127.0.0.1]) by mm01.cs.columbia.edu (Postfix) with ESMTP id 524374B133; Fri, 2 Dec 2022 11:04:21 -0500 (EST) Received: from localhost (localhost [127.0.0.1]) by mm01.cs.columbia.edu (Postfix) with ESMTP id 3C9C0411C7 for ; Fri, 2 Dec 2022 11:04:20 -0500 (EST) X-Virus-Scanned: at lists.cs.columbia.edu Received: from mm01.cs.columbia.edu ([127.0.0.1]) by localhost (mm01.cs.columbia.edu [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wqBDaLGK2Jjp for ; Fri, 2 Dec 2022 11:04:15 -0500 (EST) Received: from mail-pl1-f179.google.com (mail-pl1-f179.google.com [209.85.214.179]) by mm01.cs.columbia.edu (Postfix) with ESMTPS id 46FFA410E6 for ; Fri, 2 Dec 2022 11:04:15 -0500 (EST) Received: by mail-pl1-f179.google.com with SMTP id b21so5007492plc.9 for ; Fri, 02 Dec 2022 08:04:15 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20210112; h=in-reply-to:content-transfer-encoding:content-disposition :mime-version:references:message-id:subject:cc:to:from:date:from:to :cc:subject:date:message-id:reply-to; bh=b2GsRYGpugbtZSHFD2RurCZ4JW4xZuzTsOfxXrCkfT8=; b=NpcRjd8PL93RDmu18EFPPR+cTZLP3kvCDAEAva9wUQzgEtv6dhPvDs1R9Q9+h2mN7N H42dGaT+sl8xeMuYK2rfUD+midQutKuG+T3MUl21HeEIW4MolVpdsUIo9SmBbkggNx39 8eN3yXePSJelVozj19wEaq9z6VDhzvEr0ForIWyEXE5qa5rozQa3WxAYewh7SubIBKmO 02PPePyseXuLiMMtCMvFiCLdBEv6hZUEsP/WY2KPh2svytXFAqt8tvoUSmd0DdfZmIR5 sLez1JP4ikgagdRRPh2k9RbfsucGTq+KVdolkDHLvc/Uk58Zr0iw+nxpff3e47GDmBB4 X4Mw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=in-reply-to:content-transfer-encoding:content-disposition :mime-version:references:message-id:subject:cc:to:from:date :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=b2GsRYGpugbtZSHFD2RurCZ4JW4xZuzTsOfxXrCkfT8=; b=hARYbKIb1K3Av/XzshZ1NSTurTKurqrhxn0tf1GdjfG4zdoiO+3G+JDuXNhquOWWzE 9MPOxuZv+u2tMl2NMo3OTIK5R25ebCFWc/0PJkSiQJMDGhLnGt0Gx286OrNhaPj64fwU 8rxUxeMjCk8eWH3dF+1OLtE/lSMKjccpP4cAGk+cjsxH0UddEG4hOvC9ds0UVNyVlgzu ONfJO+zHJT8p3eWJtlnaUeih4+kMIdS2zwQexmuO1760YuwewCQnW5dujTF3UuYbPftJ mEHtgqHoeoNNWHCY4uDbOD6FbE6Y9ozvLbYQXkEkzAiLdPKGqIi3bKz7bSg0U9GvbEeE jRGg== X-Gm-Message-State: ANoB5pndUKZ021fDqNFfPosXxNnroreC7l/IDJWUdW+EJZIz/iEUkwTW 2NCaiGCDxtjIUHIqgB/SMwUIPg== X-Google-Smtp-Source: AA0mqf7w0TN/IsoZof5JEkNGBQ8Yd2Zjjhh4wCVFAlaPO07IGqPcQWl6OiCMwNp3DG6Q8B9rQJAiYA== X-Received: by 2002:a17:90a:9a98:b0:219:2f90:4fb3 with SMTP id e24-20020a17090a9a9800b002192f904fb3mr28837193pjp.109.1669997053879; Fri, 02 Dec 2022 08:04:13 -0800 (PST) Received: from google.com (7.104.168.34.bc.googleusercontent.com. [34.168.104.7]) by smtp.gmail.com with ESMTPSA id q42-20020a17090a1b2d00b00219752c8ea5sm3349337pjq.37.2022.12.02.08.04.12 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 02 Dec 2022 08:04:13 -0800 (PST) Date: Fri, 2 Dec 2022 16:04:09 +0000 From: Sean Christopherson To: "Huang, Kai" Subject: Re: [PATCH v2 40/50] KVM: x86: Do compatibility checks when onlining CPU Message-ID: References: <20221130230934.1014142-1-seanjc@google.com> <20221130230934.1014142-41-seanjc@google.com> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: Cc: "mjrosato@linux.ibm.com" , "paul@xen.org" , "Yao, Yuan" , "david@redhat.com" , "linux-mips@vger.kernel.org" , "atishp@atishpatra.org" , "mpe@ellerman.id.au" , "linux-riscv@lists.infradead.org" , "imbrenda@linux.ibm.com" , "kvmarm@lists.cs.columbia.edu" , "linux-s390@vger.kernel.org" , "frankja@linux.ibm.com" , "maz@kernel.org" , "chenhuacai@kernel.org" , "aleksandar.qemu.devel@gmail.com" , "borntraeger@linux.ibm.com" , "Gao, Chao" , "farman@linux.ibm.com" , "aou@eecs.berkeley.edu" , "kvm@vger.kernel.org" , "paul.walmsley@sifive.com" , "kvmarm@lists.linux.dev" , "tglx@linutronix.de" , "linux-arm-kernel@lists.infradead.org" , "Yamahata, Isaku" , "philmd@linaro.org" , "farosas@linux.ibm.com" , "linuxppc-dev@lists.ozlabs.org" , "cohuck@redhat.com" , "linux-kernel@vger.kernel.org" , "palmer@dabbelt.com" , "kvm-riscv@lists.infradead.org" , "pbonzini@redhat.com" , "vkuznets@redhat.com" , "dwmw2@infradead.org" X-BeenThere: kvmarm@lists.cs.columbia.edu X-Mailman-Version: 2.1.14 Precedence: list List-Id: Where KVM/ARM decisions are made List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Errors-To: kvmarm-bounces@lists.cs.columbia.edu Sender: kvmarm-bounces@lists.cs.columbia.edu On Fri, Dec 02, 2022, Huang, Kai wrote: > On Wed, 2022-11-30 at 23:09 +0000, Sean Christopherson wrote: > > --- a/arch/x86/kvm/x86.c > > +++ b/arch/x86/kvm/x86.c > > @@ -11967,6 +11967,11 @@ int kvm_arch_hardware_enable(void) > > =A0 bool stable, backwards_tsc =3D false; > > =A0 > > =A0 kvm_user_return_msr_cpu_online(); > > + > > + ret =3D kvm_x86_check_processor_compatibility(); > > + if (ret) > > + return ret; > > + > > =A0 ret =3D static_call(kvm_x86_hardware_enable)(); > > =A0 if (ret !=3D 0) > > =A0 return ret; > = > Thinking more, AFAICT, kvm_x86_vendor_init() so far still does the compat= ibility > check on all online cpus. Since now kvm_arch_hardware_enable() also does= the > compatibility check, IIUC the compatibility check will be done twice -- o= ne in > kvm_x86_vendor_init() and one in hardware_enable_all() when creating the = first > VM. > = > Do you think it's still worth to do compatibility check in vm_x86_vendor_= init()? > = > The behaviour difference should be "KVM module fail to load" vs "failing = to > create the first VM" IIUC. I don't know whether the former is better tha= n the > better, but it seems duplicated compatibility checking isn't needed? It's not strictly needed, but I think it's worth keeping. The duplicate ch= ecking annoys me too, and I considered removing it multiple times when creating th= is series. But, if there is a hardware incompatibility for whatever reason, f= ailing 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 From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-pl1-f182.google.com (mail-pl1-f182.google.com [209.85.214.182]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id D5F3A4C71 for ; Fri, 2 Dec 2022 16:04:14 +0000 (UTC) Received: by mail-pl1-f182.google.com with SMTP id d3so5007488plr.10 for ; Fri, 02 Dec 2022 08:04:14 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20210112; h=in-reply-to:content-transfer-encoding:content-disposition :mime-version:references:message-id:subject:cc:to:from:date:from:to :cc:subject:date:message-id:reply-to; bh=b2GsRYGpugbtZSHFD2RurCZ4JW4xZuzTsOfxXrCkfT8=; b=NpcRjd8PL93RDmu18EFPPR+cTZLP3kvCDAEAva9wUQzgEtv6dhPvDs1R9Q9+h2mN7N H42dGaT+sl8xeMuYK2rfUD+midQutKuG+T3MUl21HeEIW4MolVpdsUIo9SmBbkggNx39 8eN3yXePSJelVozj19wEaq9z6VDhzvEr0ForIWyEXE5qa5rozQa3WxAYewh7SubIBKmO 02PPePyseXuLiMMtCMvFiCLdBEv6hZUEsP/WY2KPh2svytXFAqt8tvoUSmd0DdfZmIR5 sLez1JP4ikgagdRRPh2k9RbfsucGTq+KVdolkDHLvc/Uk58Zr0iw+nxpff3e47GDmBB4 X4Mw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=in-reply-to:content-transfer-encoding:content-disposition :mime-version:references:message-id:subject:cc:to:from:date :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=b2GsRYGpugbtZSHFD2RurCZ4JW4xZuzTsOfxXrCkfT8=; b=d06aCWQGwM943yE57+dwZ//RXHhbua7iVv+D2hqf9DcQY8tuVlda849bv63HPXFfVb VxStyzJuAhVlCGL9ViLSq+uLVTTq6trpDXdLoxfS2J/hW8NxSLExc3PN0TBXwBPRtYH0 1qRLFTcv8o8ZkDjtx4yu2k1AOOLqV4g5k3CEtNjmCGR0nFYyj9wSQpzIbrQBqO7sURr6 Yxvn6Hu7QlUJzf5F88ypGk93GfZnhc1sImlJXzUZb/dRz2yflDozcjYCYmmrxkQr8GpE Cyhc3vKmC+ig/Cp3LzS4ETZlgNNdWK+Yz4z31C+GqfFzj4dAnoLAJ7Nabb89OhpgPUiU kexA== X-Gm-Message-State: ANoB5plJOK61EMMCmA5iy9IYdisKRC5qFB2P9APxx/tbc1TCLg8aOXPj wkOGX3Lafe6dGA5Q/q1+Ov1Dhg== X-Google-Smtp-Source: AA0mqf7w0TN/IsoZof5JEkNGBQ8Yd2Zjjhh4wCVFAlaPO07IGqPcQWl6OiCMwNp3DG6Q8B9rQJAiYA== X-Received: by 2002:a17:90a:9a98:b0:219:2f90:4fb3 with SMTP id e24-20020a17090a9a9800b002192f904fb3mr28837193pjp.109.1669997053879; Fri, 02 Dec 2022 08:04:13 -0800 (PST) Received: from google.com (7.104.168.34.bc.googleusercontent.com. [34.168.104.7]) by smtp.gmail.com with ESMTPSA id q42-20020a17090a1b2d00b00219752c8ea5sm3349337pjq.37.2022.12.02.08.04.12 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 02 Dec 2022 08:04:13 -0800 (PST) Date: Fri, 2 Dec 2022 16:04:09 +0000 From: Sean Christopherson To: "Huang, Kai" Cc: "chenhuacai@kernel.org" , "maz@kernel.org" , "frankja@linux.ibm.com" , "borntraeger@linux.ibm.com" , "farman@linux.ibm.com" , "aou@eecs.berkeley.edu" , "palmer@dabbelt.com" , "paul.walmsley@sifive.com" , "pbonzini@redhat.com" , "dwmw2@infradead.org" , "aleksandar.qemu.devel@gmail.com" , "imbrenda@linux.ibm.com" , "paul@xen.org" , "mjrosato@linux.ibm.com" , "vkuznets@redhat.com" , "anup@brainfault.org" , "oliver.upton@linux.dev" , "kvm@vger.kernel.org" , "cohuck@redhat.com" , "farosas@linux.ibm.com" , "david@redhat.com" , "james.morse@arm.com" , "Yao, Yuan" , "alexandru.elisei@arm.com" , "linux-s390@vger.kernel.org" , "linux-kernel@vger.kernel.org" , "mpe@ellerman.id.au" , "Yamahata, Isaku" , "kvmarm@lists.linux.dev" , "tglx@linutronix.de" , "suzuki.poulose@arm.com" , "kvm-riscv@lists.infradead.org" , "linuxppc-dev@lists.ozlabs.org" , "linux-arm-kernel@lists.infradead.org" , "linux-mips@vger.kernel.org" , "kvmarm@lists.cs.columbia.edu" , "philmd@linaro.org" , "atishp@atishpatra.org" , "linux-riscv@lists.infradead.org" , "Gao, Chao" Subject: Re: [PATCH v2 40/50] KVM: x86: Do compatibility checks when onlining CPU Message-ID: References: <20221130230934.1014142-1-seanjc@google.com> <20221130230934.1014142-41-seanjc@google.com> Precedence: bulk X-Mailing-List: kvmarm@lists.linux.dev List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: Message-ID: <20221202160409.n8HfVkO2XH9-RXhx5sGE4eYdei1L2VmsYZ7qabKoxyI@z> On Fri, Dec 02, 2022, Huang, Kai wrote: > On Wed, 2022-11-30 at 23:09 +0000, Sean Christopherson 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(); > > + > > + ret = kvm_x86_check_processor_compatibility(); > > + if (ret) > > + 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 > compatibility check, IIUC the compatibility check will be done twice -- one in > kvm_x86_vendor_init() and one in hardware_enable_all() when creating the first > VM. > > Do you think it's still worth to do compatibility check in vm_x86_vendor_init()? > > The behaviour difference should be "KVM module fail to load" vs "failing to > create the first VM" IIUC. I don't know whether the former is better than the > better, but it seems duplicated compatibility checking isn't needed? It's not strictly needed, but I think it's worth keeping. The duplicate checking annoys me too, and I considered removing it multiple times when creating this series. But, if there is a hardware incompatibility for whatever reason, failing 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. From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from bombadil.infradead.org (bombadil.infradead.org [198.137.202.133]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.lore.kernel.org (Postfix) with ESMTPS id 74D08C4321E for ; Fri, 2 Dec 2022 16:07:12 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=bombadil.20210309; h=Sender: Content-Transfer-Encoding:Content-Type:List-Subscribe:List-Help:List-Post: List-Archive:List-Unsubscribe:List-Id:In-Reply-To:MIME-Version:References: Message-ID:Subject:Cc:To:From:Date:Reply-To:Content-ID:Content-Description: Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID: List-Owner; bh=Jvn4NeG+aVV4297kCu5k8zVBh2K5rai21TTY6yBuSnU=; b=0HrKlmIN4JkxE+ L+2euQBctItHCjyEuSQIKD+deKgcBNqXouGhkJLFpClmCziZWW0O+PdF+N6QAJIZdGWc8Nwksiike 9Uh/MLioAnc8/sVrp3Ooc4Utfi7C1HuSy9E+pJID8J7gU1IemXHmPjHX0FC23NQl4mF1iJf+zIziG +I85CiNYcmdh3pWJ1rueS22PQPyYxHloQLSTBSxW3QamiaohWSDAfgLqHzwWhwTnejTr54qHfEOAN iVh7EM+PYcxKbNJyyUBxKEbHy7LRB9odiyTTxMTiSagoCqL51Nic26WBSdVpAe5G2/in7i65eZhy7 XjzI5kydQy3YuRTr2Bpw==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.94.2 #2 (Red Hat Linux)) id 1p18Z5-00HKo8-Pk; Fri, 02 Dec 2022 16:07:03 +0000 Received: from mail-pl1-x634.google.com ([2607:f8b0:4864:20::634]) by bombadil.infradead.org with esmtps (Exim 4.94.2 #2 (Red Hat Linux)) id 1p18WQ-00HIiC-05 for linux-riscv@lists.infradead.org; Fri, 02 Dec 2022 16:04:21 +0000 Received: by mail-pl1-x634.google.com with SMTP id jn7so4993242plb.13 for ; Fri, 02 Dec 2022 08:04:14 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20210112; h=in-reply-to:content-transfer-encoding:content-disposition :mime-version:references:message-id:subject:cc:to:from:date:from:to :cc:subject:date:message-id:reply-to; bh=b2GsRYGpugbtZSHFD2RurCZ4JW4xZuzTsOfxXrCkfT8=; b=NpcRjd8PL93RDmu18EFPPR+cTZLP3kvCDAEAva9wUQzgEtv6dhPvDs1R9Q9+h2mN7N H42dGaT+sl8xeMuYK2rfUD+midQutKuG+T3MUl21HeEIW4MolVpdsUIo9SmBbkggNx39 8eN3yXePSJelVozj19wEaq9z6VDhzvEr0ForIWyEXE5qa5rozQa3WxAYewh7SubIBKmO 02PPePyseXuLiMMtCMvFiCLdBEv6hZUEsP/WY2KPh2svytXFAqt8tvoUSmd0DdfZmIR5 sLez1JP4ikgagdRRPh2k9RbfsucGTq+KVdolkDHLvc/Uk58Zr0iw+nxpff3e47GDmBB4 X4Mw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=in-reply-to:content-transfer-encoding:content-disposition :mime-version:references:message-id:subject:cc:to:from:date :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=b2GsRYGpugbtZSHFD2RurCZ4JW4xZuzTsOfxXrCkfT8=; b=QJUhMM4pGQxaFNPPLULskRFs6qzuTNSDzCpCzkC3+AmWxJHuSRy/8E0gCnc+brbqRB vTVqUgK0Bn3KvKeCJiJPvHbPTPXm7Qbif+WXhUOQF0pvx89HlsYIQMk+6wqE4bU/j1UE ADKU7Dv4u9sZCG6536+W3IJSGPkzz6OZmBYhx92yezMs63dGfDHQsRp73Ah4fupVh2ou KeG/wtPoIcQvPcqoXBnsuOhbqO9CslsCwoRTuWy1iZpIqzwAdc73cOVlRRg8nmtfsfPr NInk/Ssht1s48R0V+uk51jmre7yzZ7QD6yFXrs6yBwkDeW3p9eY9ZE7Nggd7DlFVLrJh E6tQ== X-Gm-Message-State: ANoB5pn7QJ9k6MHWD6ST3qNuxRdMTRs3I7y9NdmXS7jVlqujNAHfu8lH x3oOFg/9Oocw7/mAgwJliEgErg== X-Google-Smtp-Source: AA0mqf7w0TN/IsoZof5JEkNGBQ8Yd2Zjjhh4wCVFAlaPO07IGqPcQWl6OiCMwNp3DG6Q8B9rQJAiYA== X-Received: by 2002:a17:90a:9a98:b0:219:2f90:4fb3 with SMTP id e24-20020a17090a9a9800b002192f904fb3mr28837193pjp.109.1669997053879; Fri, 02 Dec 2022 08:04:13 -0800 (PST) Received: from google.com (7.104.168.34.bc.googleusercontent.com. [34.168.104.7]) by smtp.gmail.com with ESMTPSA id q42-20020a17090a1b2d00b00219752c8ea5sm3349337pjq.37.2022.12.02.08.04.12 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 02 Dec 2022 08:04:13 -0800 (PST) Date: Fri, 2 Dec 2022 16:04:09 +0000 From: Sean Christopherson To: "Huang, Kai" Cc: "chenhuacai@kernel.org" , "maz@kernel.org" , "frankja@linux.ibm.com" , "borntraeger@linux.ibm.com" , "farman@linux.ibm.com" , "aou@eecs.berkeley.edu" , "palmer@dabbelt.com" , "paul.walmsley@sifive.com" , "pbonzini@redhat.com" , "dwmw2@infradead.org" , "aleksandar.qemu.devel@gmail.com" , "imbrenda@linux.ibm.com" , "paul@xen.org" , "mjrosato@linux.ibm.com" , "vkuznets@redhat.com" , "anup@brainfault.org" , "oliver.upton@linux.dev" , "kvm@vger.kernel.org" , "cohuck@redhat.com" , "farosas@linux.ibm.com" , "david@redhat.com" , "james.morse@arm.com" , "Yao, Yuan" , "alexandru.elisei@arm.com" , "linux-s390@vger.kernel.org" , "linux-kernel@vger.kernel.org" , "mpe@ellerman.id.au" , "Yamahata, Isaku" , "kvmarm@lists.linux.dev" , "tglx@linutronix.de" , "suzuki.poulose@arm.com" , "kvm-riscv@lists.infradead.org" , "linuxppc-dev@lists.ozlabs.org" , "linux-arm-kernel@lists.infradead.org" , "linux-mips@vger.kernel.org" , "kvmarm@lists.cs.columbia.edu" , "philmd@linaro.org" , "atishp@atishpatra.org" , "linux-riscv@lists.infradead.org" , "Gao, Chao" Subject: Re: [PATCH v2 40/50] KVM: x86: Do compatibility checks when onlining CPU Message-ID: References: <20221130230934.1014142-1-seanjc@google.com> <20221130230934.1014142-41-seanjc@google.com> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20221202_080418_140399_28CD1F63 X-CRM114-Status: GOOD ( 17.26 ) X-BeenThere: linux-riscv@lists.infradead.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Sender: "linux-riscv" Errors-To: linux-riscv-bounces+linux-riscv=archiver.kernel.org@lists.infradead.org On Fri, Dec 02, 2022, Huang, Kai wrote: > On Wed, 2022-11-30 at 23:09 +0000, Sean Christopherson wrote: > > --- a/arch/x86/kvm/x86.c > > +++ b/arch/x86/kvm/x86.c > > @@ -11967,6 +11967,11 @@ int kvm_arch_hardware_enable(void) > > =A0 bool stable, backwards_tsc =3D false; > > =A0 > > =A0 kvm_user_return_msr_cpu_online(); > > + > > + ret =3D kvm_x86_check_processor_compatibility(); > > + if (ret) > > + return ret; > > + > > =A0 ret =3D static_call(kvm_x86_hardware_enable)(); > > =A0 if (ret !=3D 0) > > =A0 return ret; > = > Thinking more, AFAICT, kvm_x86_vendor_init() so far still does the compat= ibility > check on all online cpus. Since now kvm_arch_hardware_enable() also does= the > compatibility check, IIUC the compatibility check will be done twice -- o= ne in > kvm_x86_vendor_init() and one in hardware_enable_all() when creating the = first > VM. > = > Do you think it's still worth to do compatibility check in vm_x86_vendor_= init()? > = > The behaviour difference should be "KVM module fail to load" vs "failing = to > create the first VM" IIUC. I don't know whether the former is better tha= n the > better, but it seems duplicated compatibility checking isn't needed? It's not strictly needed, but I think it's worth keeping. The duplicate ch= ecking annoys me too, and I considered removing it multiple times when creating th= is series. But, if there is a hardware incompatibility for whatever reason, f= ailing 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 From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from lists.ozlabs.org (lists.ozlabs.org [112.213.38.117]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.lore.kernel.org (Postfix) with ESMTPS id 32F70C47089 for ; Fri, 2 Dec 2022 16:08:08 +0000 (UTC) Received: from boromir.ozlabs.org (localhost [IPv6:::1]) by lists.ozlabs.org (Postfix) with ESMTP id 4NNyXQ65nhz3fNP for ; Sat, 3 Dec 2022 03:08:06 +1100 (AEDT) Authentication-Results: lists.ozlabs.org; dkim=fail reason="signature verification failed" (2048-bit key; unprotected) header.d=google.com header.i=@google.com header.a=rsa-sha256 header.s=20210112 header.b=NpcRjd8P; dkim-atps=neutral Authentication-Results: lists.ozlabs.org; spf=pass (sender SPF authorized) smtp.mailfrom=google.com (client-ip=2607:f8b0:4864:20::102f; helo=mail-pj1-x102f.google.com; envelope-from=seanjc@google.com; receiver=) Authentication-Results: lists.ozlabs.org; dkim=pass (2048-bit key; unprotected) header.d=google.com header.i=@google.com header.a=rsa-sha256 header.s=20210112 header.b=NpcRjd8P; dkim-atps=neutral Received: from mail-pj1-x102f.google.com (mail-pj1-x102f.google.com [IPv6:2607:f8b0:4864:20::102f]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by lists.ozlabs.org (Postfix) with ESMTPS id 4NNyS31wj8z3c6d for ; Sat, 3 Dec 2022 03:04:18 +1100 (AEDT) Received: by mail-pj1-x102f.google.com with SMTP id q17-20020a17090aa01100b002194cba32e9so8728178pjp.1 for ; Fri, 02 Dec 2022 08:04:18 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20210112; h=in-reply-to:content-transfer-encoding:content-disposition :mime-version:references:message-id:subject:cc:to:from:date:from:to :cc:subject:date:message-id:reply-to; bh=b2GsRYGpugbtZSHFD2RurCZ4JW4xZuzTsOfxXrCkfT8=; b=NpcRjd8PL93RDmu18EFPPR+cTZLP3kvCDAEAva9wUQzgEtv6dhPvDs1R9Q9+h2mN7N H42dGaT+sl8xeMuYK2rfUD+midQutKuG+T3MUl21HeEIW4MolVpdsUIo9SmBbkggNx39 8eN3yXePSJelVozj19wEaq9z6VDhzvEr0ForIWyEXE5qa5rozQa3WxAYewh7SubIBKmO 02PPePyseXuLiMMtCMvFiCLdBEv6hZUEsP/WY2KPh2svytXFAqt8tvoUSmd0DdfZmIR5 sLez1JP4ikgagdRRPh2k9RbfsucGTq+KVdolkDHLvc/Uk58Zr0iw+nxpff3e47GDmBB4 X4Mw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=in-reply-to:content-transfer-encoding:content-disposition :mime-version:references:message-id:subject:cc:to:from:date :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=b2GsRYGpugbtZSHFD2RurCZ4JW4xZuzTsOfxXrCkfT8=; b=0WqvqSrZoIsV15vwpJy7FcUx/6jhfYPP5oDfbqYkAi//tqA+MMvfs70QvCY9/FldEk KJACqySagWsHUJAIMWDL3/46+zh92Amtp+BaC2d2On3E8I4dom2qCLgU3EjsXt+hNSTo TBY13Huv0sc481C5eZ2CM8WVKGauA0bQHxrp0r7ImD7+1or5g6/WGBZhTBRadbB3Amwh hIN6WQ9E+gNpxKW9hO8b6msh4W2MHlOV9r7TUffTe9og8jLahbJYCZ8WFNbTh5J0Y1in MpZ9izsUWt1TvGZ0syUGodFwY57c6QUgI4ILWhGPNNsX7i5D0F4GjK9CGm6N+AF8xvq8 n52w== X-Gm-Message-State: ANoB5pmKY3zecxsWC8oWJRkb76Ctd1E2zU637r8cqNDGLkmGTjpm4eXH immFRx3QWfqSRvpz2Y1SbauBEw== X-Google-Smtp-Source: AA0mqf7w0TN/IsoZof5JEkNGBQ8Yd2Zjjhh4wCVFAlaPO07IGqPcQWl6OiCMwNp3DG6Q8B9rQJAiYA== X-Received: by 2002:a17:90a:9a98:b0:219:2f90:4fb3 with SMTP id e24-20020a17090a9a9800b002192f904fb3mr28837193pjp.109.1669997053879; Fri, 02 Dec 2022 08:04:13 -0800 (PST) Received: from google.com (7.104.168.34.bc.googleusercontent.com. [34.168.104.7]) by smtp.gmail.com with ESMTPSA id q42-20020a17090a1b2d00b00219752c8ea5sm3349337pjq.37.2022.12.02.08.04.12 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 02 Dec 2022 08:04:13 -0800 (PST) Date: Fri, 2 Dec 2022 16:04:09 +0000 From: Sean Christopherson To: "Huang, Kai" Subject: Re: [PATCH v2 40/50] KVM: x86: Do compatibility checks when onlining CPU Message-ID: References: <20221130230934.1014142-1-seanjc@google.com> <20221130230934.1014142-41-seanjc@google.com> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: X-BeenThere: linuxppc-dev@lists.ozlabs.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Linux on PowerPC Developers Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: "mjrosato@linux.ibm.com" , "paul@xen.org" , "Yao, Yuan" , "david@redhat.com" , "linux-mips@vger.kernel.org" , "atishp@atishpatra.org" , "linux-riscv@lists.infradead.org" , "imbrenda@linux.ibm.com" , "kvmarm@lists.cs.columbia.edu" , "linux-s390@vger.kernel.org" , "frankja@linux.ibm.com" , "maz@kernel.org" , "chenhuacai@kernel.org" , "aleksandar.qemu.devel@gmail.com" , "james.morse@arm.com" , "borntraeger@linux.ibm.com" , "Gao, Chao" , "farman@linux.ibm.com" , "aou@eecs.berkeley.edu" , "suzuki.poulose@arm.com" , "kvm @vger.kernel.org" , "paul.walmsley@sifive.com" , "kvmarm@lists.linux.dev" , "tglx@linutronix.de" , "alexandru.elisei@arm.com" , "linux-arm-kernel@lists.infradead.org" , "Yamahata, Isaku" , "philmd@linaro.org" , "farosas@linux.ibm.com" , "linuxppc-dev@lists.ozlabs.org" , "cohuck@redhat.com" , "linux-kernel@vger.kernel.org" , "oliver.upton@linux.dev" , "palmer@dabbelt.com" , "kvm-riscv@lists.infradead.org" , "anup@brainfault.org" , "pbonzini@redhat.com" , "vkuznets@redhat.com" , "dwmw2@infradead.org" Errors-To: linuxppc-dev-bounces+linuxppc-dev=archiver.kernel.org@lists.ozlabs.org Sender: "Linuxppc-dev" On Fri, Dec 02, 2022, Huang, Kai wrote: > On Wed, 2022-11-30 at 23:09 +0000, Sean Christopherson 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(); > > + > > + ret = kvm_x86_check_processor_compatibility(); > > + if (ret) > > + 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 > compatibility check, IIUC the compatibility check will be done twice -- one in > kvm_x86_vendor_init() and one in hardware_enable_all() when creating the first > VM. > > Do you think it's still worth to do compatibility check in vm_x86_vendor_init()? > > The behaviour difference should be "KVM module fail to load" vs "failing to > create the first VM" IIUC. I don't know whether the former is better than the > better, but it seems duplicated compatibility checking isn't needed? It's not strictly needed, but I think it's worth keeping. The duplicate checking annoys me too, and I considered removing it multiple times when creating this series. But, if there is a hardware incompatibility for whatever reason, failing 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. From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from bombadil.infradead.org (bombadil.infradead.org [198.137.202.133]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.lore.kernel.org (Postfix) with ESMTPS id 96824C4321E for ; Fri, 2 Dec 2022 16:08:48 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=bombadil.20210309; h=Sender: Content-Transfer-Encoding:Content-Type:List-Subscribe:List-Help:List-Post: List-Archive:List-Unsubscribe:List-Id:In-Reply-To:MIME-Version:References: Message-ID:Subject:Cc:To:From:Date:Reply-To:Content-ID:Content-Description: Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID: List-Owner; bh=0lVvgSWBX9kbj5tWztepxfo+06jw+mpVHz3q3gcyIq4=; b=SQA2XcxV2FtUdv wvbEgCjEDbb2qXYrHWYnCiuKJ2tGj0CvO+63wgufR6k7I3El9XtNHa+sqEn6piKBuYg1+ERdUHBE9 qphPRxT0AwMnopCZGM+U1EI1b2plei0OlEbYXWoBi8hzxIy/3AYCLKqUbARDft245cPqhfr2s3XRf v21wknd/km6hvIrWgtm3g4XV8AZsLscQEIy+ALMY5rWtiAhgzqZUsYIFvdDItdUQyn0Yf96quuRZ4 BWcrHoEAccYQ3RvuK8tzHsgKp60AvFPrUsovYmJW6gV8bnJFjYR3omgzPU2oTQ9rd7ZAJivT/9EFe bmwyEZCQoOqx+M5zoTLQ==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.94.2 #2 (Red Hat Linux)) id 1p18ZC-00HKr1-Bi; Fri, 02 Dec 2022 16:07:10 +0000 Received: from mail-pl1-x634.google.com ([2607:f8b0:4864:20::634]) by bombadil.infradead.org with esmtps (Exim 4.94.2 #2 (Red Hat Linux)) id 1p18WP-00HIiB-WB for linux-arm-kernel@lists.infradead.org; Fri, 02 Dec 2022 16:04:21 +0000 Received: by mail-pl1-x634.google.com with SMTP id y4so5025188plb.2 for ; Fri, 02 Dec 2022 08:04:14 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20210112; h=in-reply-to:content-transfer-encoding:content-disposition :mime-version:references:message-id:subject:cc:to:from:date:from:to :cc:subject:date:message-id:reply-to; bh=b2GsRYGpugbtZSHFD2RurCZ4JW4xZuzTsOfxXrCkfT8=; b=NpcRjd8PL93RDmu18EFPPR+cTZLP3kvCDAEAva9wUQzgEtv6dhPvDs1R9Q9+h2mN7N H42dGaT+sl8xeMuYK2rfUD+midQutKuG+T3MUl21HeEIW4MolVpdsUIo9SmBbkggNx39 8eN3yXePSJelVozj19wEaq9z6VDhzvEr0ForIWyEXE5qa5rozQa3WxAYewh7SubIBKmO 02PPePyseXuLiMMtCMvFiCLdBEv6hZUEsP/WY2KPh2svytXFAqt8tvoUSmd0DdfZmIR5 sLez1JP4ikgagdRRPh2k9RbfsucGTq+KVdolkDHLvc/Uk58Zr0iw+nxpff3e47GDmBB4 X4Mw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=in-reply-to:content-transfer-encoding:content-disposition :mime-version:references:message-id:subject:cc:to:from:date :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=b2GsRYGpugbtZSHFD2RurCZ4JW4xZuzTsOfxXrCkfT8=; b=6uW2DusVKD1G6C56uBU+WmdnpveRGMh5IeFvw0yxSqfjJpfTjk2hr+uKQt98Uh9/S5 /TLaI556Wn1t0y92TjUbRqCixrABclM8QXRZvF85SSI0px2j2uHs0Oyh/0Uf6srUt6bC kEZVOMFKpTQ2CKzofmocTloLXLMFWpDFpNH/Jnf/7owUlWOK2z+Pyi2shy4YUfKnEz8K 7scf6k/clbVJyG44CRbn+fZkDiwcEPq2LpoqB6AymSseYFH8/idM7DCNntj7lEMB2wzr Pgo4OzK+O1eRp++0iMgQlv1j4seqOLPU1gaPkRJIbd2oS0axT3AicGaLGADgyOlJHGP+ jIMw== X-Gm-Message-State: ANoB5pmgJWQKzu2G9RGNmmWgxXsCMqFiqUBGPextFPfuSP8Rxv9lAsQK CwI8xddEDkZbi8bsxkyUqK8SaQ== X-Google-Smtp-Source: AA0mqf7w0TN/IsoZof5JEkNGBQ8Yd2Zjjhh4wCVFAlaPO07IGqPcQWl6OiCMwNp3DG6Q8B9rQJAiYA== X-Received: by 2002:a17:90a:9a98:b0:219:2f90:4fb3 with SMTP id e24-20020a17090a9a9800b002192f904fb3mr28837193pjp.109.1669997053879; Fri, 02 Dec 2022 08:04:13 -0800 (PST) Received: from google.com (7.104.168.34.bc.googleusercontent.com. [34.168.104.7]) by smtp.gmail.com with ESMTPSA id q42-20020a17090a1b2d00b00219752c8ea5sm3349337pjq.37.2022.12.02.08.04.12 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 02 Dec 2022 08:04:13 -0800 (PST) Date: Fri, 2 Dec 2022 16:04:09 +0000 From: Sean Christopherson To: "Huang, Kai" Cc: "chenhuacai@kernel.org" , "maz@kernel.org" , "frankja@linux.ibm.com" , "borntraeger@linux.ibm.com" , "farman@linux.ibm.com" , "aou@eecs.berkeley.edu" , "palmer@dabbelt.com" , "paul.walmsley@sifive.com" , "pbonzini@redhat.com" , "dwmw2@infradead.org" , "aleksandar.qemu.devel@gmail.com" , "imbrenda@linux.ibm.com" , "paul@xen.org" , "mjrosato@linux.ibm.com" , "vkuznets@redhat.com" , "anup@brainfault.org" , "oliver.upton@linux.dev" , "kvm@vger.kernel.org" , "cohuck@redhat.com" , "farosas@linux.ibm.com" , "david@redhat.com" , "james.morse@arm.com" , "Yao, Yuan" , "alexandru.elisei@arm.com" , "linux-s390@vger.kernel.org" , "linux-kernel@vger.kernel.org" , "mpe@ellerman.id.au" , "Yamahata, Isaku" , "kvmarm@lists.linux.dev" , "tglx@linutronix.de" , "suzuki.poulose@arm.com" , "kvm-riscv@lists.infradead.org" , "linuxppc-dev@lists.ozlabs.org" , "linux-arm-kernel@lists.infradead.org" , "linux-mips@vger.kernel.org" , "kvmarm@lists.cs.columbia.edu" , "philmd@linaro.org" , "atishp@atishpatra.org" , "linux-riscv@lists.infradead.org" , "Gao, Chao" Subject: Re: [PATCH v2 40/50] KVM: x86: Do compatibility checks when onlining CPU Message-ID: References: <20221130230934.1014142-1-seanjc@google.com> <20221130230934.1014142-41-seanjc@google.com> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20221202_080418_129320_2F18F951 X-CRM114-Status: GOOD ( 18.73 ) X-BeenThere: linux-arm-kernel@lists.infradead.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org On Fri, Dec 02, 2022, Huang, Kai wrote: > On Wed, 2022-11-30 at 23:09 +0000, Sean Christopherson wrote: > > --- a/arch/x86/kvm/x86.c > > +++ b/arch/x86/kvm/x86.c > > @@ -11967,6 +11967,11 @@ int kvm_arch_hardware_enable(void) > > =A0 bool stable, backwards_tsc =3D false; > > =A0 > > =A0 kvm_user_return_msr_cpu_online(); > > + > > + ret =3D kvm_x86_check_processor_compatibility(); > > + if (ret) > > + return ret; > > + > > =A0 ret =3D static_call(kvm_x86_hardware_enable)(); > > =A0 if (ret !=3D 0) > > =A0 return ret; > = > Thinking more, AFAICT, kvm_x86_vendor_init() so far still does the compat= ibility > check on all online cpus. Since now kvm_arch_hardware_enable() also does= the > compatibility check, IIUC the compatibility check will be done twice -- o= ne in > kvm_x86_vendor_init() and one in hardware_enable_all() when creating the = first > VM. > = > Do you think it's still worth to do compatibility check in vm_x86_vendor_= init()? > = > The behaviour difference should be "KVM module fail to load" vs "failing = to > create the first VM" IIUC. I don't know whether the former is better tha= n the > better, but it seems duplicated compatibility checking isn't needed? It's not strictly needed, but I think it's worth keeping. The duplicate ch= ecking annoys me too, and I considered removing it multiple times when creating th= is series. But, if there is a hardware incompatibility for whatever reason, f= ailing 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