From mboxrd@z Thu Jan 1 00:00:00 1970 From: Sean Christopherson Date: Fri, 4 Nov 2022 15:40:36 +0000 Subject: [PATCH 33/44] KVM: x86: Do VMX/SVM support checks directly in vendor code In-Reply-To: <6c71fcca-c17f-5979-e15e-afcf08899064@redhat.com> References: <20221102231911.3107438-1-seanjc@google.com> <20221102231911.3107438-34-seanjc@google.com> <6c71fcca-c17f-5979-e15e-afcf08899064@redhat.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, Nov 04, 2022, Paolo Bonzini wrote: > On 11/3/22 19:58, Sean Christopherson wrote: > > > > diff --git a/arch/x86/kernel/cpu/common.c b/arch/x86/kernel/cpu/common.c > > index 3e508f239098..ebe617ab0b37 100644 > > --- a/arch/x86/kernel/cpu/common.c > > +++ b/arch/x86/kernel/cpu/common.c > > @@ -191,6 +191,8 @@ static void default_init(struct cpuinfo_x86 *c) > > strcpy(c->x86_model_id, "386"); > > } > > #endif > > + > > + clear_cpu_cap(c, X86_FEATURE_MSR_IA32_FEAT_CTL); > > } > > static const struct cpu_dev default_cpu = { > > Not needed I think? default_init does not call init_ia32_feat_ctl. cpuid_deps is only processed by do_clear_cpu_cap(), so unless there's an explicit "clear" action, the dependencies will not be updated. It kinda makes sense since hardware-based features shouldn't end up with scenarios where a dependent feature exists but the base feature does not (barring bad KVM setups :-) ). That said, this seems like a bug waiting to happen, and unless I'm missing something it's quite straightforward to process all dependencies during setup. Time to find out if Boris and co. agree :-) diff --git a/arch/x86/include/asm/cpufeature.h b/arch/x86/include/asm/cpufeature.h index 1a85e1fb0922..c4408d03b180 100644 --- a/arch/x86/include/asm/cpufeature.h +++ b/arch/x86/include/asm/cpufeature.h @@ -147,6 +147,7 @@ extern const char * const x86_bug_flags[NBUGINTS*32]; extern void setup_clear_cpu_cap(unsigned int bit); extern void clear_cpu_cap(struct cpuinfo_x86 *c, unsigned int bit); +extern void apply_cpuid_deps(struct cpuinfo_x86 *c); #define setup_force_cpu_cap(bit) do { \ set_cpu_cap(&boot_cpu_data, bit); \ diff --git a/arch/x86/kernel/cpu/common.c b/arch/x86/kernel/cpu/common.c index 3e508f239098..28ce31dadd7f 100644 --- a/arch/x86/kernel/cpu/common.c +++ b/arch/x86/kernel/cpu/common.c @@ -1884,6 +1884,8 @@ static void identify_cpu(struct cpuinfo_x86 *c) c->x86_capability[i] |= boot_cpu_data.x86_capability[i]; } + apply_cpuid_deps(c); + ppin_init(c); /* Init Machine Check Exception if available. */ diff --git a/arch/x86/kernel/cpu/cpuid-deps.c b/arch/x86/kernel/cpu/cpuid-deps.c index c881bcafba7d..7e91e97973ca 100644 --- a/arch/x86/kernel/cpu/cpuid-deps.c +++ b/arch/x86/kernel/cpu/cpuid-deps.c @@ -138,3 +138,13 @@ void setup_clear_cpu_cap(unsigned int feature) { do_clear_cpu_cap(NULL, feature); } + +void apply_cpuid_deps(struct cpuinfo_x86 *c) +{ + const struct cpuid_dep *d; + + for (d = cpuid_deps; d->feature; d++) { + if (!cpu_has(c, d->feature)) + clear_cpu_cap(c, d->feature); + } +} 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 4FF2FC4332F for ; Fri, 4 Nov 2022 15:40:45 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by mm01.cs.columbia.edu (Postfix) with ESMTP id B552C40EEF; Fri, 4 Nov 2022 11:40:44 -0400 (EDT) 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 2NhRuVAST4da; Fri, 4 Nov 2022 11:40:43 -0400 (EDT) Received: from mm01.cs.columbia.edu (localhost [127.0.0.1]) by mm01.cs.columbia.edu (Postfix) with ESMTP id 984B140762; Fri, 4 Nov 2022 11:40:43 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by mm01.cs.columbia.edu (Postfix) with ESMTP id 570A0403AD for ; Fri, 4 Nov 2022 11:40:42 -0400 (EDT) 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 12t8hnBYutku for ; Fri, 4 Nov 2022 11:40:41 -0400 (EDT) Received: from mail-pf1-f180.google.com (mail-pf1-f180.google.com [209.85.210.180]) by mm01.cs.columbia.edu (Postfix) with ESMTPS id 134E0402ED for ; Fri, 4 Nov 2022 11:40:40 -0400 (EDT) Received: by mail-pf1-f180.google.com with SMTP id d10so4833513pfh.6 for ; Fri, 04 Nov 2022 08:40:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20210112; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:from:to:cc:subject:date:message-id:reply-to; bh=aFlTeUJ4nQplolWHip6FrS/j8TYR0+QbDmRZAFvu7G8=; b=slnKaxTVWka5uyvV8ksftk1iXtqkYG7wonGPtAtNy/P6RP4ZnWhdbZSV/6seXnMCof dnF6JUiRfV2oVCETco2jEIOQzRouLfUDiH7vxFD2orQpNLxCcfMVtLr6ntSOZeUo+8A4 1WMtzeSAIQ00ZBggEzItHUadG+pi52a6RW5LTbSCWNWQHjLySk/BPh9TembQq8ly6ISW XBS14fXfAOCGbRuWccsHUKA4no5JdNrqlAYc2mDDTkISHx1kXdJjDDClXTXp09r2HKHF 4YYshPvOotdfKVbVnw4u/+IsxQ4NAMvmIrkrc7+c9m8NGZEp/7DC/KTLI5ge39pksAS0 M2/g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=in-reply-to: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=aFlTeUJ4nQplolWHip6FrS/j8TYR0+QbDmRZAFvu7G8=; b=1k9+wL1S7FEqLLDSITVmFpoMbxCsQB3nmGkaJktDxaBeLsqX1Bxn/8U/0lo0Nw2d0i 9JBuQJA6TSnimRFk3szc8jnSbXfdQVUx8kAg+2Rt/Z9iaXbOIvmtrHyNBc/84o4R5XTV GpbE/PiqRevzfByZui/B9KsL1WciHVLiWMg0KzJhm5P4+65M7Wlg9KioNjvOEk0oUv07 GAUhoihigAMsRwlsia/c9MiTmO2agedEXqrIO/E/zBFK78/WcWG7cUdd+F+jX222/T2s luxzkBUxY7ni84QuDB2inUmbT0IfEIeDSw+sivZxdGDmibV5siWdwrRysxGMbR+bsOId FxFQ== X-Gm-Message-State: ACrzQf1sEC3XtSI7xIuPEyfzcUHQ6KashDzh7T+G4CsvUXsvG0+LDY6J rM9SCHizs0WZtmY50YFucR537A== X-Google-Smtp-Source: AMsMyM5MdI5VKNUr37j2LDfWFXfSalVZ70lqDfROHdw5vEhrWbzDEJP2xBkjkN31VBShKB5D+mx4vA== X-Received: by 2002:a62:1a8d:0:b0:544:1309:19f3 with SMTP id a135-20020a621a8d000000b00544130919f3mr36549720pfa.37.1667576439875; Fri, 04 Nov 2022 08:40:39 -0700 (PDT) Received: from google.com (7.104.168.34.bc.googleusercontent.com. [34.168.104.7]) by smtp.gmail.com with ESMTPSA id y133-20020a62ce8b000000b00565cbad9616sm2905778pfg.6.2022.11.04.08.40.39 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 04 Nov 2022 08:40:39 -0700 (PDT) Date: Fri, 4 Nov 2022 15:40:36 +0000 From: Sean Christopherson To: Paolo Bonzini Subject: Re: [PATCH 33/44] KVM: x86: Do VMX/SVM support checks directly in vendor code Message-ID: References: <20221102231911.3107438-1-seanjc@google.com> <20221102231911.3107438-34-seanjc@google.com> <6c71fcca-c17f-5979-e15e-afcf08899064@redhat.com> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <6c71fcca-c17f-5979-e15e-afcf08899064@redhat.com> Cc: Matthew Rosato , David Hildenbrand , Yuan Yao , Paul Walmsley , linux-kernel@vger.kernel.org, Michael Ellerman , linux-riscv@lists.infradead.org, Claudio Imbrenda , kvmarm@lists.cs.columbia.edu, linux-s390@vger.kernel.org, Janosch Frank , Marc Zyngier , Huacai Chen , Aleksandar Markovic , Christian Borntraeger , Chao Gao , Eric Farman , Albert Ou , kvm@vger.kernel.org, Atish Patra , kvmarm@lists.linux.dev, Thomas Gleixner , linux-arm-kernel@lists.infradead.org, Isaku Yamahata , Fabiano Rosas , linux-mips@vger.kernel.org, Palmer Dabbelt , kvm-riscv@lists.infradead.org, Vitaly Kuznetsov , linuxppc-dev@lists.ozlabs.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="us-ascii" Content-Transfer-Encoding: 7bit Errors-To: kvmarm-bounces@lists.cs.columbia.edu Sender: kvmarm-bounces@lists.cs.columbia.edu On Fri, Nov 04, 2022, Paolo Bonzini wrote: > On 11/3/22 19:58, Sean Christopherson wrote: > > > > diff --git a/arch/x86/kernel/cpu/common.c b/arch/x86/kernel/cpu/common.c > > index 3e508f239098..ebe617ab0b37 100644 > > --- a/arch/x86/kernel/cpu/common.c > > +++ b/arch/x86/kernel/cpu/common.c > > @@ -191,6 +191,8 @@ static void default_init(struct cpuinfo_x86 *c) > > strcpy(c->x86_model_id, "386"); > > } > > #endif > > + > > + clear_cpu_cap(c, X86_FEATURE_MSR_IA32_FEAT_CTL); > > } > > static const struct cpu_dev default_cpu = { > > Not needed I think? default_init does not call init_ia32_feat_ctl. cpuid_deps is only processed by do_clear_cpu_cap(), so unless there's an explicit "clear" action, the dependencies will not be updated. It kinda makes sense since hardware-based features shouldn't end up with scenarios where a dependent feature exists but the base feature does not (barring bad KVM setups :-) ). That said, this seems like a bug waiting to happen, and unless I'm missing something it's quite straightforward to process all dependencies during setup. Time to find out if Boris and co. agree :-) diff --git a/arch/x86/include/asm/cpufeature.h b/arch/x86/include/asm/cpufeature.h index 1a85e1fb0922..c4408d03b180 100644 --- a/arch/x86/include/asm/cpufeature.h +++ b/arch/x86/include/asm/cpufeature.h @@ -147,6 +147,7 @@ extern const char * const x86_bug_flags[NBUGINTS*32]; extern void setup_clear_cpu_cap(unsigned int bit); extern void clear_cpu_cap(struct cpuinfo_x86 *c, unsigned int bit); +extern void apply_cpuid_deps(struct cpuinfo_x86 *c); #define setup_force_cpu_cap(bit) do { \ set_cpu_cap(&boot_cpu_data, bit); \ diff --git a/arch/x86/kernel/cpu/common.c b/arch/x86/kernel/cpu/common.c index 3e508f239098..28ce31dadd7f 100644 --- a/arch/x86/kernel/cpu/common.c +++ b/arch/x86/kernel/cpu/common.c @@ -1884,6 +1884,8 @@ static void identify_cpu(struct cpuinfo_x86 *c) c->x86_capability[i] |= boot_cpu_data.x86_capability[i]; } + apply_cpuid_deps(c); + ppin_init(c); /* Init Machine Check Exception if available. */ diff --git a/arch/x86/kernel/cpu/cpuid-deps.c b/arch/x86/kernel/cpu/cpuid-deps.c index c881bcafba7d..7e91e97973ca 100644 --- a/arch/x86/kernel/cpu/cpuid-deps.c +++ b/arch/x86/kernel/cpu/cpuid-deps.c @@ -138,3 +138,13 @@ void setup_clear_cpu_cap(unsigned int feature) { do_clear_cpu_cap(NULL, feature); } + +void apply_cpuid_deps(struct cpuinfo_x86 *c) +{ + const struct cpuid_dep *d; + + for (d = cpuid_deps; d->feature; d++) { + if (!cpu_has(c, d->feature)) + clear_cpu_cap(c, d->feature); + } +} _______________________________________________ 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-pg1-f169.google.com (mail-pg1-f169.google.com [209.85.215.169]) (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 93CFD1C3F for ; Fri, 4 Nov 2022 15:40:40 +0000 (UTC) Received: by mail-pg1-f169.google.com with SMTP id b5so4686106pgb.6 for ; Fri, 04 Nov 2022 08:40:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20210112; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:from:to:cc:subject:date:message-id:reply-to; bh=aFlTeUJ4nQplolWHip6FrS/j8TYR0+QbDmRZAFvu7G8=; b=slnKaxTVWka5uyvV8ksftk1iXtqkYG7wonGPtAtNy/P6RP4ZnWhdbZSV/6seXnMCof dnF6JUiRfV2oVCETco2jEIOQzRouLfUDiH7vxFD2orQpNLxCcfMVtLr6ntSOZeUo+8A4 1WMtzeSAIQ00ZBggEzItHUadG+pi52a6RW5LTbSCWNWQHjLySk/BPh9TembQq8ly6ISW XBS14fXfAOCGbRuWccsHUKA4no5JdNrqlAYc2mDDTkISHx1kXdJjDDClXTXp09r2HKHF 4YYshPvOotdfKVbVnw4u/+IsxQ4NAMvmIrkrc7+c9m8NGZEp/7DC/KTLI5ge39pksAS0 M2/g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=in-reply-to: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=aFlTeUJ4nQplolWHip6FrS/j8TYR0+QbDmRZAFvu7G8=; b=MM8Nk0fVCBNv+DuY2ANeO0afmIeuJAeWWVppwjDl/5bwd3q61GQILx6DgL+4Ulmkd+ 3FBu9MWS6mo9G8TsdyBQkYfLXHd3yS3NoKpkwZt8WPnzSYNmA1c96/qEwaFhLvoylDpi 4slr7ZtQt+ALAPtAVC/17a9/n3wlYECR683+TYcUm/xYfGbLRx3WCAU/NroX49T0VabZ mgPUxGUem9TKWKegsLpYn88fNjnI15QAeZb2RvUGQn0Bo6VqwXSBXBtF4qzudMs2amco xRoSGzLoHqgFjxov0XSkoB9EqgBVkRMaUODmBdOZ75gZBNrY4x6BbDmLcApdmjPQG+QU jA1w== X-Gm-Message-State: ACrzQf0911gDGSMFCbzX7b8x0uXRv4VEYrB64NczfPvXqxVXssUB05KP u2JQSE6VY4iQObq4DGgKWWfpmQ== X-Google-Smtp-Source: AMsMyM5MdI5VKNUr37j2LDfWFXfSalVZ70lqDfROHdw5vEhrWbzDEJP2xBkjkN31VBShKB5D+mx4vA== X-Received: by 2002:a62:1a8d:0:b0:544:1309:19f3 with SMTP id a135-20020a621a8d000000b00544130919f3mr36549720pfa.37.1667576439875; Fri, 04 Nov 2022 08:40:39 -0700 (PDT) Received: from google.com (7.104.168.34.bc.googleusercontent.com. [34.168.104.7]) by smtp.gmail.com with ESMTPSA id y133-20020a62ce8b000000b00565cbad9616sm2905778pfg.6.2022.11.04.08.40.39 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 04 Nov 2022 08:40:39 -0700 (PDT) Date: Fri, 4 Nov 2022 15:40:36 +0000 From: Sean Christopherson To: Paolo Bonzini Cc: Marc Zyngier , Huacai Chen , Aleksandar Markovic , Anup Patel , Paul Walmsley , Palmer Dabbelt , Albert Ou , Christian Borntraeger , Janosch Frank , Claudio Imbrenda , Matthew Rosato , Eric Farman , Vitaly Kuznetsov , James Morse , Alexandru Elisei , Suzuki K Poulose , Oliver Upton , Atish Patra , David Hildenbrand , kvm@vger.kernel.org, linux-arm-kernel@lists.infradead.org, kvmarm@lists.linux.dev, kvmarm@lists.cs.columbia.edu, linux-mips@vger.kernel.org, linuxppc-dev@lists.ozlabs.org, kvm-riscv@lists.infradead.org, linux-riscv@lists.infradead.org, linux-s390@vger.kernel.org, linux-kernel@vger.kernel.org, Isaku Yamahata , Fabiano Rosas , Michael Ellerman , Chao Gao , Thomas Gleixner , Yuan Yao Subject: Re: [PATCH 33/44] KVM: x86: Do VMX/SVM support checks directly in vendor code Message-ID: References: <20221102231911.3107438-1-seanjc@google.com> <20221102231911.3107438-34-seanjc@google.com> <6c71fcca-c17f-5979-e15e-afcf08899064@redhat.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=us-ascii Content-Disposition: inline In-Reply-To: <6c71fcca-c17f-5979-e15e-afcf08899064@redhat.com> Message-ID: <20221104154036.nvfH20WCx-SqLj941lj_TJdSt1jE--7lOY066upKHUY@z> On Fri, Nov 04, 2022, Paolo Bonzini wrote: > On 11/3/22 19:58, Sean Christopherson wrote: > > > > diff --git a/arch/x86/kernel/cpu/common.c b/arch/x86/kernel/cpu/common.c > > index 3e508f239098..ebe617ab0b37 100644 > > --- a/arch/x86/kernel/cpu/common.c > > +++ b/arch/x86/kernel/cpu/common.c > > @@ -191,6 +191,8 @@ static void default_init(struct cpuinfo_x86 *c) > > strcpy(c->x86_model_id, "386"); > > } > > #endif > > + > > + clear_cpu_cap(c, X86_FEATURE_MSR_IA32_FEAT_CTL); > > } > > static const struct cpu_dev default_cpu = { > > Not needed I think? default_init does not call init_ia32_feat_ctl. cpuid_deps is only processed by do_clear_cpu_cap(), so unless there's an explicit "clear" action, the dependencies will not be updated. It kinda makes sense since hardware-based features shouldn't end up with scenarios where a dependent feature exists but the base feature does not (barring bad KVM setups :-) ). That said, this seems like a bug waiting to happen, and unless I'm missing something it's quite straightforward to process all dependencies during setup. Time to find out if Boris and co. agree :-) diff --git a/arch/x86/include/asm/cpufeature.h b/arch/x86/include/asm/cpufeature.h index 1a85e1fb0922..c4408d03b180 100644 --- a/arch/x86/include/asm/cpufeature.h +++ b/arch/x86/include/asm/cpufeature.h @@ -147,6 +147,7 @@ extern const char * const x86_bug_flags[NBUGINTS*32]; extern void setup_clear_cpu_cap(unsigned int bit); extern void clear_cpu_cap(struct cpuinfo_x86 *c, unsigned int bit); +extern void apply_cpuid_deps(struct cpuinfo_x86 *c); #define setup_force_cpu_cap(bit) do { \ set_cpu_cap(&boot_cpu_data, bit); \ diff --git a/arch/x86/kernel/cpu/common.c b/arch/x86/kernel/cpu/common.c index 3e508f239098..28ce31dadd7f 100644 --- a/arch/x86/kernel/cpu/common.c +++ b/arch/x86/kernel/cpu/common.c @@ -1884,6 +1884,8 @@ static void identify_cpu(struct cpuinfo_x86 *c) c->x86_capability[i] |= boot_cpu_data.x86_capability[i]; } + apply_cpuid_deps(c); + ppin_init(c); /* Init Machine Check Exception if available. */ diff --git a/arch/x86/kernel/cpu/cpuid-deps.c b/arch/x86/kernel/cpu/cpuid-deps.c index c881bcafba7d..7e91e97973ca 100644 --- a/arch/x86/kernel/cpu/cpuid-deps.c +++ b/arch/x86/kernel/cpu/cpuid-deps.c @@ -138,3 +138,13 @@ void setup_clear_cpu_cap(unsigned int feature) { do_clear_cpu_cap(NULL, feature); } + +void apply_cpuid_deps(struct cpuinfo_x86 *c) +{ + const struct cpuid_dep *d; + + for (d = cpuid_deps; d->feature; d++) { + if (!cpu_has(c, d->feature)) + clear_cpu_cap(c, d->feature); + } +} 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 50BF0C4332F for ; Fri, 4 Nov 2022 15:41:00 +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=HN6deqFxnimJdgrcgHHnFpxheDR6zf7zC2twZf8qnRQ=; b=Nu9LKqy1+kq41d JJTuhbmUaE+xkhW+oK2PIHR1NH/zAklnlQ9mIqBzmC4KhmpNtxt3MxwlrPeQvNJB2OIUc2czxXdBy xH1cgW3ZVWQXz94One+Ufu1qr5NuwfBGbQPLHvdq8uaLK/TWxDfXTFZgxXl69QJ67RzXe92dtY5AS PE3mODzXUAWTysluLzam8vHoUaJvdJ0mC12vfc+r4oA2wd5/UDXlmEa/SGVlZLlJ+gwlWKhheWZKA a8+x1TDpXQY2JT46qewXYPf+fVuBiGJKT/WHMtB3kAS6S0QvCw0rv4PIMjZNFHX+K3ZXcx2d86VFJ fW3adyD+NZ/6iGsyWPyw==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.94.2 #2 (Red Hat Linux)) id 1oqyoJ-004Hxq-9r; Fri, 04 Nov 2022 15:40:47 +0000 Received: from mail-pf1-x433.google.com ([2607:f8b0:4864:20::433]) by bombadil.infradead.org with esmtps (Exim 4.94.2 #2 (Red Hat Linux)) id 1oqyoE-004Hu0-AC for linux-riscv@lists.infradead.org; Fri, 04 Nov 2022 15:40:44 +0000 Received: by mail-pf1-x433.google.com with SMTP id i3so4820355pfc.11 for ; Fri, 04 Nov 2022 08:40:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20210112; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:from:to:cc:subject:date:message-id:reply-to; bh=aFlTeUJ4nQplolWHip6FrS/j8TYR0+QbDmRZAFvu7G8=; b=slnKaxTVWka5uyvV8ksftk1iXtqkYG7wonGPtAtNy/P6RP4ZnWhdbZSV/6seXnMCof dnF6JUiRfV2oVCETco2jEIOQzRouLfUDiH7vxFD2orQpNLxCcfMVtLr6ntSOZeUo+8A4 1WMtzeSAIQ00ZBggEzItHUadG+pi52a6RW5LTbSCWNWQHjLySk/BPh9TembQq8ly6ISW XBS14fXfAOCGbRuWccsHUKA4no5JdNrqlAYc2mDDTkISHx1kXdJjDDClXTXp09r2HKHF 4YYshPvOotdfKVbVnw4u/+IsxQ4NAMvmIrkrc7+c9m8NGZEp/7DC/KTLI5ge39pksAS0 M2/g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=in-reply-to: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=aFlTeUJ4nQplolWHip6FrS/j8TYR0+QbDmRZAFvu7G8=; b=6VLeJdRVfDFekZkXCdkvVY/J3+/qx6wnItwzWaTSjOgmgcqMp1i9BRl/698AP0XUOT Cmt7O+nqXlwbBmS/4VGMYNua4sTLJzQgXBumI3eayx/7M6IQVJWA61l7M4C+Ud2+XcP6 6K05Rh1OQuUdJLQWZWTwOwVn8nNrextLWLX+x1p0jJ0wFABFAMNAzbOhRvym1phJOn3E vSPfSi0zFjiHhxG1du1Dg5+xJjsOa/mikbad7m7BjE7tXgDtKbCRcyXd+LuInujBbQal VtCj62HXbhHxCSYW5143rsoXh3Bwnl/+hm2/PQvzxYOnSJKS0h5lGJmFCwWhGw/eJeiO P7eg== X-Gm-Message-State: ACrzQf023iingIWBpHSGxwixIK7/EpR/dSzb4WY9bOhDTwSAukCOdtzM Io6G90T1XnWZUoMfvp11tN99vA== X-Google-Smtp-Source: AMsMyM5MdI5VKNUr37j2LDfWFXfSalVZ70lqDfROHdw5vEhrWbzDEJP2xBkjkN31VBShKB5D+mx4vA== X-Received: by 2002:a62:1a8d:0:b0:544:1309:19f3 with SMTP id a135-20020a621a8d000000b00544130919f3mr36549720pfa.37.1667576439875; Fri, 04 Nov 2022 08:40:39 -0700 (PDT) Received: from google.com (7.104.168.34.bc.googleusercontent.com. [34.168.104.7]) by smtp.gmail.com with ESMTPSA id y133-20020a62ce8b000000b00565cbad9616sm2905778pfg.6.2022.11.04.08.40.39 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 04 Nov 2022 08:40:39 -0700 (PDT) Date: Fri, 4 Nov 2022 15:40:36 +0000 From: Sean Christopherson To: Paolo Bonzini Cc: Marc Zyngier , Huacai Chen , Aleksandar Markovic , Anup Patel , Paul Walmsley , Palmer Dabbelt , Albert Ou , Christian Borntraeger , Janosch Frank , Claudio Imbrenda , Matthew Rosato , Eric Farman , Vitaly Kuznetsov , James Morse , Alexandru Elisei , Suzuki K Poulose , Oliver Upton , Atish Patra , David Hildenbrand , kvm@vger.kernel.org, linux-arm-kernel@lists.infradead.org, kvmarm@lists.linux.dev, kvmarm@lists.cs.columbia.edu, linux-mips@vger.kernel.org, linuxppc-dev@lists.ozlabs.org, kvm-riscv@lists.infradead.org, linux-riscv@lists.infradead.org, linux-s390@vger.kernel.org, linux-kernel@vger.kernel.org, Isaku Yamahata , Fabiano Rosas , Michael Ellerman , Chao Gao , Thomas Gleixner , Yuan Yao Subject: Re: [PATCH 33/44] KVM: x86: Do VMX/SVM support checks directly in vendor code Message-ID: References: <20221102231911.3107438-1-seanjc@google.com> <20221102231911.3107438-34-seanjc@google.com> <6c71fcca-c17f-5979-e15e-afcf08899064@redhat.com> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <6c71fcca-c17f-5979-e15e-afcf08899064@redhat.com> X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20221104_084042_410603_80CB279B X-CRM114-Status: GOOD ( 14.90 ) 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="us-ascii" Content-Transfer-Encoding: 7bit Sender: "linux-riscv" Errors-To: linux-riscv-bounces+linux-riscv=archiver.kernel.org@lists.infradead.org On Fri, Nov 04, 2022, Paolo Bonzini wrote: > On 11/3/22 19:58, Sean Christopherson wrote: > > > > diff --git a/arch/x86/kernel/cpu/common.c b/arch/x86/kernel/cpu/common.c > > index 3e508f239098..ebe617ab0b37 100644 > > --- a/arch/x86/kernel/cpu/common.c > > +++ b/arch/x86/kernel/cpu/common.c > > @@ -191,6 +191,8 @@ static void default_init(struct cpuinfo_x86 *c) > > strcpy(c->x86_model_id, "386"); > > } > > #endif > > + > > + clear_cpu_cap(c, X86_FEATURE_MSR_IA32_FEAT_CTL); > > } > > static const struct cpu_dev default_cpu = { > > Not needed I think? default_init does not call init_ia32_feat_ctl. cpuid_deps is only processed by do_clear_cpu_cap(), so unless there's an explicit "clear" action, the dependencies will not be updated. It kinda makes sense since hardware-based features shouldn't end up with scenarios where a dependent feature exists but the base feature does not (barring bad KVM setups :-) ). That said, this seems like a bug waiting to happen, and unless I'm missing something it's quite straightforward to process all dependencies during setup. Time to find out if Boris and co. agree :-) diff --git a/arch/x86/include/asm/cpufeature.h b/arch/x86/include/asm/cpufeature.h index 1a85e1fb0922..c4408d03b180 100644 --- a/arch/x86/include/asm/cpufeature.h +++ b/arch/x86/include/asm/cpufeature.h @@ -147,6 +147,7 @@ extern const char * const x86_bug_flags[NBUGINTS*32]; extern void setup_clear_cpu_cap(unsigned int bit); extern void clear_cpu_cap(struct cpuinfo_x86 *c, unsigned int bit); +extern void apply_cpuid_deps(struct cpuinfo_x86 *c); #define setup_force_cpu_cap(bit) do { \ set_cpu_cap(&boot_cpu_data, bit); \ diff --git a/arch/x86/kernel/cpu/common.c b/arch/x86/kernel/cpu/common.c index 3e508f239098..28ce31dadd7f 100644 --- a/arch/x86/kernel/cpu/common.c +++ b/arch/x86/kernel/cpu/common.c @@ -1884,6 +1884,8 @@ static void identify_cpu(struct cpuinfo_x86 *c) c->x86_capability[i] |= boot_cpu_data.x86_capability[i]; } + apply_cpuid_deps(c); + ppin_init(c); /* Init Machine Check Exception if available. */ diff --git a/arch/x86/kernel/cpu/cpuid-deps.c b/arch/x86/kernel/cpu/cpuid-deps.c index c881bcafba7d..7e91e97973ca 100644 --- a/arch/x86/kernel/cpu/cpuid-deps.c +++ b/arch/x86/kernel/cpu/cpuid-deps.c @@ -138,3 +138,13 @@ void setup_clear_cpu_cap(unsigned int feature) { do_clear_cpu_cap(NULL, feature); } + +void apply_cpuid_deps(struct cpuinfo_x86 *c) +{ + const struct cpuid_dep *d; + + for (d = cpuid_deps; d->feature; d++) { + if (!cpu_has(c, d->feature)) + clear_cpu_cap(c, d->feature); + } +} _______________________________________________ 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 E047DC43217 for ; Fri, 4 Nov 2022 15:41:47 +0000 (UTC) Received: from boromir.ozlabs.org (localhost [IPv6:::1]) by lists.ozlabs.org (Postfix) with ESMTP id 4N3lGy0Tdqz3cMf for ; Sat, 5 Nov 2022 02:41:46 +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=slnKaxTV; dkim-atps=neutral Authentication-Results: lists.ozlabs.org; spf=pass (sender SPF authorized) smtp.mailfrom=google.com (client-ip=2607:f8b0:4864:20::534; helo=mail-pg1-x534.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=slnKaxTV; dkim-atps=neutral Received: from mail-pg1-x534.google.com (mail-pg1-x534.google.com [IPv6:2607:f8b0:4864:20::534]) (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 4N3lFs2n9Qz3c6M for ; Sat, 5 Nov 2022 02:40:48 +1100 (AEDT) Received: by mail-pg1-x534.google.com with SMTP id 136so823230pga.1 for ; Fri, 04 Nov 2022 08:40:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20210112; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:from:to:cc:subject:date:message-id:reply-to; bh=aFlTeUJ4nQplolWHip6FrS/j8TYR0+QbDmRZAFvu7G8=; b=slnKaxTVWka5uyvV8ksftk1iXtqkYG7wonGPtAtNy/P6RP4ZnWhdbZSV/6seXnMCof dnF6JUiRfV2oVCETco2jEIOQzRouLfUDiH7vxFD2orQpNLxCcfMVtLr6ntSOZeUo+8A4 1WMtzeSAIQ00ZBggEzItHUadG+pi52a6RW5LTbSCWNWQHjLySk/BPh9TembQq8ly6ISW XBS14fXfAOCGbRuWccsHUKA4no5JdNrqlAYc2mDDTkISHx1kXdJjDDClXTXp09r2HKHF 4YYshPvOotdfKVbVnw4u/+IsxQ4NAMvmIrkrc7+c9m8NGZEp/7DC/KTLI5ge39pksAS0 M2/g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=in-reply-to: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=aFlTeUJ4nQplolWHip6FrS/j8TYR0+QbDmRZAFvu7G8=; b=pFpdY6bncsPOdKd98JwDkB8Gq+NrEkiaa6+8JgrzfTh8mJMaxo6MbeQmoUnXJSZnsD eEnBNx4e+bWqc4kGt6yriyvdV/vdRBx2yOUOY/QsnMeh+UoOS+Ck7NpHBPiMB1WeESDe r6r3E/PkKf1BdtBBPkyEWxCE5Jojau54Qe+8Is7KiQKgrPUghvyT+MybMhA3/2kAMcvR EayQkwbOWPFHMf7mJsKOL9/ee+pO3J6aiCXvPMJbDnKSkU5kYZFFcQmkiOmkMgRbwXnN 7mQ4L73drZSFb75JkJLQaf3dU53CsLZ04/apvunUU46c7rFeeq5OG7diH2jWgbQmMzA4 KKpg== X-Gm-Message-State: ACrzQf0mgEvilGTagSGMbAvQPKpE8ZxMnnC+nDBoPbn2QiBXs+GPwDtP PJF/l1MyQz5chrRkVRV6t0HwJA== X-Google-Smtp-Source: AMsMyM5MdI5VKNUr37j2LDfWFXfSalVZ70lqDfROHdw5vEhrWbzDEJP2xBkjkN31VBShKB5D+mx4vA== X-Received: by 2002:a62:1a8d:0:b0:544:1309:19f3 with SMTP id a135-20020a621a8d000000b00544130919f3mr36549720pfa.37.1667576439875; Fri, 04 Nov 2022 08:40:39 -0700 (PDT) Received: from google.com (7.104.168.34.bc.googleusercontent.com. [34.168.104.7]) by smtp.gmail.com with ESMTPSA id y133-20020a62ce8b000000b00565cbad9616sm2905778pfg.6.2022.11.04.08.40.39 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 04 Nov 2022 08:40:39 -0700 (PDT) Date: Fri, 4 Nov 2022 15:40:36 +0000 From: Sean Christopherson To: Paolo Bonzini Subject: Re: [PATCH 33/44] KVM: x86: Do VMX/SVM support checks directly in vendor code Message-ID: References: <20221102231911.3107438-1-seanjc@google.com> <20221102231911.3107438-34-seanjc@google.com> <6c71fcca-c17f-5979-e15e-afcf08899064@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <6c71fcca-c17f-5979-e15e-afcf08899064@redhat.com> 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: Matthew Rosato , David Hildenbrand , Yuan Yao , Paul Walmsley , linux-kernel@vger.kernel.org, linux-riscv@lists.infradead.org, Claudio Imbrenda , kvmarm@lists.cs.columbia.edu, linux-s390@vger.kernel.org, Janosch Frank , Marc Zyngier , Huacai Chen , Aleksandar Markovic , James Morse , Christian Borntraeger , Chao Gao , Eric Farman , Albert Ou , Suzuki K Poulose , kvm@vger.kernel.org, Atish Patra , kvmarm@lists.linux.dev, Thomas Gleixner , Alexandru Elisei , linux-arm-kernel@lists.infradead.org, Isaku Yamahata , Fabiano Rosas , linux-mips@vger.kernel.org, Oliver Upton , Palmer Dabbelt , kvm-riscv@lists.infradead.org, Anup Patel , Vitaly Kuznetsov , linuxppc-dev@lists.ozlabs.org Errors-To: linuxppc-dev-bounces+linuxppc-dev=archiver.kernel.org@lists.ozlabs.org Sender: "Linuxppc-dev" On Fri, Nov 04, 2022, Paolo Bonzini wrote: > On 11/3/22 19:58, Sean Christopherson wrote: > > > > diff --git a/arch/x86/kernel/cpu/common.c b/arch/x86/kernel/cpu/common.c > > index 3e508f239098..ebe617ab0b37 100644 > > --- a/arch/x86/kernel/cpu/common.c > > +++ b/arch/x86/kernel/cpu/common.c > > @@ -191,6 +191,8 @@ static void default_init(struct cpuinfo_x86 *c) > > strcpy(c->x86_model_id, "386"); > > } > > #endif > > + > > + clear_cpu_cap(c, X86_FEATURE_MSR_IA32_FEAT_CTL); > > } > > static const struct cpu_dev default_cpu = { > > Not needed I think? default_init does not call init_ia32_feat_ctl. cpuid_deps is only processed by do_clear_cpu_cap(), so unless there's an explicit "clear" action, the dependencies will not be updated. It kinda makes sense since hardware-based features shouldn't end up with scenarios where a dependent feature exists but the base feature does not (barring bad KVM setups :-) ). That said, this seems like a bug waiting to happen, and unless I'm missing something it's quite straightforward to process all dependencies during setup. Time to find out if Boris and co. agree :-) diff --git a/arch/x86/include/asm/cpufeature.h b/arch/x86/include/asm/cpufeature.h index 1a85e1fb0922..c4408d03b180 100644 --- a/arch/x86/include/asm/cpufeature.h +++ b/arch/x86/include/asm/cpufeature.h @@ -147,6 +147,7 @@ extern const char * const x86_bug_flags[NBUGINTS*32]; extern void setup_clear_cpu_cap(unsigned int bit); extern void clear_cpu_cap(struct cpuinfo_x86 *c, unsigned int bit); +extern void apply_cpuid_deps(struct cpuinfo_x86 *c); #define setup_force_cpu_cap(bit) do { \ set_cpu_cap(&boot_cpu_data, bit); \ diff --git a/arch/x86/kernel/cpu/common.c b/arch/x86/kernel/cpu/common.c index 3e508f239098..28ce31dadd7f 100644 --- a/arch/x86/kernel/cpu/common.c +++ b/arch/x86/kernel/cpu/common.c @@ -1884,6 +1884,8 @@ static void identify_cpu(struct cpuinfo_x86 *c) c->x86_capability[i] |= boot_cpu_data.x86_capability[i]; } + apply_cpuid_deps(c); + ppin_init(c); /* Init Machine Check Exception if available. */ diff --git a/arch/x86/kernel/cpu/cpuid-deps.c b/arch/x86/kernel/cpu/cpuid-deps.c index c881bcafba7d..7e91e97973ca 100644 --- a/arch/x86/kernel/cpu/cpuid-deps.c +++ b/arch/x86/kernel/cpu/cpuid-deps.c @@ -138,3 +138,13 @@ void setup_clear_cpu_cap(unsigned int feature) { do_clear_cpu_cap(NULL, feature); } + +void apply_cpuid_deps(struct cpuinfo_x86 *c) +{ + const struct cpuid_dep *d; + + for (d = cpuid_deps; d->feature; d++) { + if (!cpu_has(c, d->feature)) + clear_cpu_cap(c, d->feature); + } +} 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 4E270C4332F for ; Fri, 4 Nov 2022 15:42:02 +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=APcP2k+2Dq2OH9Wg3S7zKAqUne5iXw2EmJOswI6a38c=; b=o2hMVKD3RIxvlK RB69TyihgZA021U6Xui5yrlxvAz0abCnbgM+8a+SbNttDFF/+2z1EzX/8w2LcO97lA9lUbyP0V/LY WvgxNb7YylmBOnhC/YZ0IwJiUV5++/bvbuceoFHZk6RPQ6161HeEJRJUr5Iz14xaCYVFavaefLbKa zlt8zns3r/LnmznJGIG8NHplYzs2xIN+XNHBn66tOa26yYbZ2mZYL7HruPAYZt8AL/L4Dhte77Zwb 3yWLjIZjZm5PIFAM5RhFAr0yphzcITcL/9ypMtm08sxN8QhVmHE036heaMDti1jelA+t4KvR+pygY WHlXGOJ3d4S1HMXS4cAQ==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.94.2 #2 (Red Hat Linux)) id 1oqyoP-004I0a-GW; Fri, 04 Nov 2022 15:40:53 +0000 Received: from mail-pf1-x42f.google.com ([2607:f8b0:4864:20::42f]) by bombadil.infradead.org with esmtps (Exim 4.94.2 #2 (Red Hat Linux)) id 1oqyoE-004Hu2-Tm for linux-arm-kernel@lists.infradead.org; Fri, 04 Nov 2022 15:40:44 +0000 Received: by mail-pf1-x42f.google.com with SMTP id d10so4833516pfh.6 for ; Fri, 04 Nov 2022 08:40:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20210112; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:from:to:cc:subject:date:message-id:reply-to; bh=aFlTeUJ4nQplolWHip6FrS/j8TYR0+QbDmRZAFvu7G8=; b=slnKaxTVWka5uyvV8ksftk1iXtqkYG7wonGPtAtNy/P6RP4ZnWhdbZSV/6seXnMCof dnF6JUiRfV2oVCETco2jEIOQzRouLfUDiH7vxFD2orQpNLxCcfMVtLr6ntSOZeUo+8A4 1WMtzeSAIQ00ZBggEzItHUadG+pi52a6RW5LTbSCWNWQHjLySk/BPh9TembQq8ly6ISW XBS14fXfAOCGbRuWccsHUKA4no5JdNrqlAYc2mDDTkISHx1kXdJjDDClXTXp09r2HKHF 4YYshPvOotdfKVbVnw4u/+IsxQ4NAMvmIrkrc7+c9m8NGZEp/7DC/KTLI5ge39pksAS0 M2/g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=in-reply-to: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=aFlTeUJ4nQplolWHip6FrS/j8TYR0+QbDmRZAFvu7G8=; b=dTI2ElpcTCcgHblYjPaQ2ReuLknjeO8IGmx07lTSwrOzlIIl74PQUCZfMdFYznT3ag CEkva7P00ssOc7XhaSUOZxhC0WuFCcQ4R9+N8IBcrjg6RZEDRsIsguDHhJMDa6kmWpt9 vyXvcPQ1h1dkWK0sAFw1slUK+mMHaJ4y4wBn5mtrRzwNsoO+0LwLLbcv+OOPXkkqyfz3 q9/jTkW+qCy94oO4iIC+bca+wGpGChC2bWfkI7XzUxHshHGJh8HHLaT/gtdvc9rrDL+C GPRjdZS+ojdLjzF3urL1EpObT4AuciFkdZ8WJnxO8YxA9YNjYQN2ssszQPilgQscmz2t w3cw== X-Gm-Message-State: ACrzQf0vSQxifSwgy4cizZ0CBMmRQmk21kRx4ITGO07hkecAxjeB1G+I rWumz5jWbNXyRNJSQYbM5h2/Bw== X-Google-Smtp-Source: AMsMyM5MdI5VKNUr37j2LDfWFXfSalVZ70lqDfROHdw5vEhrWbzDEJP2xBkjkN31VBShKB5D+mx4vA== X-Received: by 2002:a62:1a8d:0:b0:544:1309:19f3 with SMTP id a135-20020a621a8d000000b00544130919f3mr36549720pfa.37.1667576439875; Fri, 04 Nov 2022 08:40:39 -0700 (PDT) Received: from google.com (7.104.168.34.bc.googleusercontent.com. [34.168.104.7]) by smtp.gmail.com with ESMTPSA id y133-20020a62ce8b000000b00565cbad9616sm2905778pfg.6.2022.11.04.08.40.39 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 04 Nov 2022 08:40:39 -0700 (PDT) Date: Fri, 4 Nov 2022 15:40:36 +0000 From: Sean Christopherson To: Paolo Bonzini Cc: Marc Zyngier , Huacai Chen , Aleksandar Markovic , Anup Patel , Paul Walmsley , Palmer Dabbelt , Albert Ou , Christian Borntraeger , Janosch Frank , Claudio Imbrenda , Matthew Rosato , Eric Farman , Vitaly Kuznetsov , James Morse , Alexandru Elisei , Suzuki K Poulose , Oliver Upton , Atish Patra , David Hildenbrand , kvm@vger.kernel.org, linux-arm-kernel@lists.infradead.org, kvmarm@lists.linux.dev, kvmarm@lists.cs.columbia.edu, linux-mips@vger.kernel.org, linuxppc-dev@lists.ozlabs.org, kvm-riscv@lists.infradead.org, linux-riscv@lists.infradead.org, linux-s390@vger.kernel.org, linux-kernel@vger.kernel.org, Isaku Yamahata , Fabiano Rosas , Michael Ellerman , Chao Gao , Thomas Gleixner , Yuan Yao Subject: Re: [PATCH 33/44] KVM: x86: Do VMX/SVM support checks directly in vendor code Message-ID: References: <20221102231911.3107438-1-seanjc@google.com> <20221102231911.3107438-34-seanjc@google.com> <6c71fcca-c17f-5979-e15e-afcf08899064@redhat.com> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <6c71fcca-c17f-5979-e15e-afcf08899064@redhat.com> X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20221104_084042_982822_00823215 X-CRM114-Status: GOOD ( 16.42 ) 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="us-ascii" Content-Transfer-Encoding: 7bit Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org On Fri, Nov 04, 2022, Paolo Bonzini wrote: > On 11/3/22 19:58, Sean Christopherson wrote: > > > > diff --git a/arch/x86/kernel/cpu/common.c b/arch/x86/kernel/cpu/common.c > > index 3e508f239098..ebe617ab0b37 100644 > > --- a/arch/x86/kernel/cpu/common.c > > +++ b/arch/x86/kernel/cpu/common.c > > @@ -191,6 +191,8 @@ static void default_init(struct cpuinfo_x86 *c) > > strcpy(c->x86_model_id, "386"); > > } > > #endif > > + > > + clear_cpu_cap(c, X86_FEATURE_MSR_IA32_FEAT_CTL); > > } > > static const struct cpu_dev default_cpu = { > > Not needed I think? default_init does not call init_ia32_feat_ctl. cpuid_deps is only processed by do_clear_cpu_cap(), so unless there's an explicit "clear" action, the dependencies will not be updated. It kinda makes sense since hardware-based features shouldn't end up with scenarios where a dependent feature exists but the base feature does not (barring bad KVM setups :-) ). That said, this seems like a bug waiting to happen, and unless I'm missing something it's quite straightforward to process all dependencies during setup. Time to find out if Boris and co. agree :-) diff --git a/arch/x86/include/asm/cpufeature.h b/arch/x86/include/asm/cpufeature.h index 1a85e1fb0922..c4408d03b180 100644 --- a/arch/x86/include/asm/cpufeature.h +++ b/arch/x86/include/asm/cpufeature.h @@ -147,6 +147,7 @@ extern const char * const x86_bug_flags[NBUGINTS*32]; extern void setup_clear_cpu_cap(unsigned int bit); extern void clear_cpu_cap(struct cpuinfo_x86 *c, unsigned int bit); +extern void apply_cpuid_deps(struct cpuinfo_x86 *c); #define setup_force_cpu_cap(bit) do { \ set_cpu_cap(&boot_cpu_data, bit); \ diff --git a/arch/x86/kernel/cpu/common.c b/arch/x86/kernel/cpu/common.c index 3e508f239098..28ce31dadd7f 100644 --- a/arch/x86/kernel/cpu/common.c +++ b/arch/x86/kernel/cpu/common.c @@ -1884,6 +1884,8 @@ static void identify_cpu(struct cpuinfo_x86 *c) c->x86_capability[i] |= boot_cpu_data.x86_capability[i]; } + apply_cpuid_deps(c); + ppin_init(c); /* Init Machine Check Exception if available. */ diff --git a/arch/x86/kernel/cpu/cpuid-deps.c b/arch/x86/kernel/cpu/cpuid-deps.c index c881bcafba7d..7e91e97973ca 100644 --- a/arch/x86/kernel/cpu/cpuid-deps.c +++ b/arch/x86/kernel/cpu/cpuid-deps.c @@ -138,3 +138,13 @@ void setup_clear_cpu_cap(unsigned int feature) { do_clear_cpu_cap(NULL, feature); } + +void apply_cpuid_deps(struct cpuinfo_x86 *c) +{ + const struct cpuid_dep *d; + + for (d = cpuid_deps; d->feature; d++) { + if (!cpu_has(c, d->feature)) + clear_cpu_cap(c, d->feature); + } +} _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel