From: Sean Christopherson <seanjc@google.com>
To: Thomas Gleixner <tglx@linutronix.de>,
Ingo Molnar <mingo@redhat.com>, Borislav Petkov <bp@alien8.de>,
Dave Hansen <dave.hansen@linux.intel.com>,
x86@kernel.org, Sean Christopherson <seanjc@google.com>,
Paolo Bonzini <pbonzini@redhat.com>
Cc: "H. Peter Anvin" <hpa@zytor.com>,
linux-kernel@vger.kernel.org, kvm@vger.kernel.org
Subject: [PATCH 0/3] x86/cpu: KVM: Make SGX and VMX depend on FEAT_CTL
Date: Sat, 3 Dec 2022 00:37:42 +0000 [thread overview]
Message-ID: <20221203003745.1475584-1-seanjc@google.com> (raw)
"Officially" make SGX and VMX depend on X86_FEATURE_MSR_IA32_FEAT_CTL,
and drop manual checks on X86_FEATURE_MSR_IA32_FEAT_CTL when querying
VMX support.
To make dependencies on MSR_IA32_FEAT_CTL work as expected, process all
CPUID dependencies at the end of CPU indentification. Because
MSR_IA32_FEAT_CTL is a synthetic flag, it is effectively off-by-default,
and thus may never be unset via clear_cpu_cap(), i.e. never triggers
processing of its dependents.
The obvious alternative would be to explicitly clear MSR_IA32_FEAT_CTL if
the MSR is unsupported, but that ends up being rather ugly as it would
require clearing the flag in default_init() to handle the scenario where
hardware supports the MSR, but the kernel was built without support for the
CPU vendor. E.g. running on an Intel CPU with CPU_SUP_INTEL=n. This edge
case is also why the existing manual checks in KVM are necessary; KVM_INTEL
effectively depends on any of CPU_SUP_{INTEL,CENATUR,ZHAOXIN}.
Processing all dependencies also seems like the correct thing to do across
the board, e.g. if the kernel ends up with more synthetic features with
dependents.
The placement of the call to apply_cpuid_deps() isn't super scientific. I
placed it after, AFAICT, the overwhelming majority of cpu cap updates had
already been done, but before anything was likely to want the dependencies
to be processed. Specifically, I couldn't find any set_cpu_caps() in the
machine check code, but there are definitely cpu_has() calls under
mcheck_cpu_init().
Last thought, patch 3 will conflict with at least one in-flight KVM series[*].
The conflict should be straightfoward to resolve, but at the same time this
is far from urgent, i.e. kicking this series down the road until KVM settles
down is totally ok.
[*] https://lore.kernel.org/all/20221130230934.1014142-1-seanjc@google.com
Sean Christopherson (3):
x86/cpu: Process all CPUID dependencies after identifying CPU info
x86/cpu: Mark SGX and VMX as being dependent on MSR_IA32_FEAT_CTL
KVM: VMX: Drop manual checks on X86_FEATURE_MSR_IA32_FEAT_CTL
arch/x86/include/asm/cpufeature.h | 1 +
arch/x86/kernel/cpu/bugs.c | 3 +--
arch/x86/kernel/cpu/common.c | 6 ++++++
arch/x86/kernel/cpu/cpuid-deps.c | 12 ++++++++++++
arch/x86/kernel/cpu/feat_ctl.c | 3 +--
arch/x86/kvm/vmx/vmx.c | 6 ++----
6 files changed, 23 insertions(+), 8 deletions(-)
base-commit: d800169041c0e035160c8b81f30d4b7e8f8ef777
--
2.39.0.rc0.267.gcb52ba06e7-goog
next reply other threads:[~2022-12-03 0:40 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-12-03 0:37 Sean Christopherson [this message]
2022-12-03 0:37 ` [PATCH 1/3] x86/cpu: Process all CPUID dependencies after identifying CPU info Sean Christopherson
2022-12-08 16:14 ` Borislav Petkov
2022-12-08 16:26 ` Sean Christopherson
2022-12-08 16:45 ` Borislav Petkov
2023-01-04 21:02 ` Sean Christopherson
2023-01-04 22:55 ` Borislav Petkov
2023-01-04 23:18 ` Sean Christopherson
2023-01-05 10:15 ` Borislav Petkov
2022-12-03 0:37 ` [PATCH 2/3] x86/cpu: Mark SGX and VMX as being dependent on MSR_IA32_FEAT_CTL Sean Christopherson
2022-12-03 0:37 ` [PATCH 3/3] KVM: VMX: Drop manual checks on X86_FEATURE_MSR_IA32_FEAT_CTL Sean Christopherson
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20221203003745.1475584-1-seanjc@google.com \
--to=seanjc@google.com \
--cc=bp@alien8.de \
--cc=dave.hansen@linux.intel.com \
--cc=hpa@zytor.com \
--cc=kvm@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=mingo@redhat.com \
--cc=pbonzini@redhat.com \
--cc=tglx@linutronix.de \
--cc=x86@kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
all inboxes | Powered by JetHome®