From: Sean Christopherson <seanjc@google.com>
To: Jim Mattson <jmattson@google.com>
Cc: kvm@vger.kernel.org, pbonzini@redhat.com
Subject: Re: [PATCH v2 2/2] KVM: x86: Expose Predictive Store Forwarding Disable on Intel parts
Date: Tue, 30 Aug 2022 23:38:59 +0000 [thread overview]
Message-ID: <Yw6fkyJrsu/i+Byy@google.com> (raw)
In-Reply-To: <20220830225210.2381310-2-jmattson@google.com>
On Tue, Aug 30, 2022, Jim Mattson wrote:
> Intel enumerates support for PSFD in CPUID.(EAX=7,ECX=2):EDX.PSFD[bit
> 0]. Report support for this feature in KVM if it is available on the
> host.
>
> Presumably, this feature bit, like its AMD counterpart, is not welcome
> in cpufeatures.h, so add a local definition of this feature in KVM.
>
> Signed-off-by: Jim Mattson <jmattson@google.com>
> ---
> arch/x86/kvm/cpuid.c | 23 +++++++++++++++++------
> 1 file changed, 17 insertions(+), 6 deletions(-)
>
> diff --git a/arch/x86/kvm/cpuid.c b/arch/x86/kvm/cpuid.c
> index 07be45c5bb93..b5af9e451bef 100644
> --- a/arch/x86/kvm/cpuid.c
> +++ b/arch/x86/kvm/cpuid.c
> @@ -62,6 +62,7 @@ u32 xstate_required_size(u64 xstate_bv, bool compacted)
> * This one is tied to SSB in the user API, and not
> * visible in /proc/cpuinfo.
> */
> +#define KVM_X86_FEATURE_PSFD 0 /* Predictive Store Forwarding Disable */
I believe we can use "enum kvm_only_cpuid_leafs" to handle this. E.g.
enum kvm_only_cpuid_leafs {
CPUID_12_EAX = NCAPINTS,
CPUID_7_2_EDX,
NR_KVM_CPU_CAPS,
NKVMCAPINTS = NR_KVM_CPU_CAPS - NCAPINTS,
};
then the intended use of KVM_X86_FEATURE_*
#define KVM_X86_FEATURE_PSFD KVM_X86_FEATURE(CPUID_7_2_EDX, 0)
I _think_ we can then define an arbitrary word for X86_FEATURE_PSFD, e.g.
#define X86_FEATURE_PSFD (NKVMCAPINTS*32+0)
and then wire up the translation:
static __always_inline u32 __feature_translate(int x86_feature)
{
if (x86_feature == X86_FEATURE_SGX1)
return KVM_X86_FEATURE_SGX1;
else if (x86_feature == X86_FEATURE_SGX2)
return KVM_X86_FEATURE_SGX2;
else if (x86_feature == X86_FEATURE_PSFD)
return KVM_X86_FEATURE_PSFD;
return x86_feature;
}
I believe/hope that allows us to use at least cpuid_entry_override(). Open coding
masking of specific registers was a mess that I don't want to repeat.
next prev parent reply other threads:[~2022-08-30 23:39 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-08-30 22:52 [PATCH v2 1/2] KVM: x86: Insert "AMD" in KVM_X86_FEATURE_PSFD Jim Mattson
2022-08-30 22:52 ` [PATCH v2 2/2] KVM: x86: Expose Predictive Store Forwarding Disable on Intel parts Jim Mattson
2022-08-30 23:38 ` Sean Christopherson [this message]
2022-08-30 23:46 ` Jim Mattson
2022-10-19 14:42 ` Sean Christopherson
2022-08-30 23:27 ` [PATCH v2 1/2] KVM: x86: Insert "AMD" in KVM_X86_FEATURE_PSFD Sean Christopherson
2022-08-30 23:32 ` Jim Mattson
2022-10-22 9:12 ` Paolo Bonzini
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=Yw6fkyJrsu/i+Byy@google.com \
--to=seanjc@google.com \
--cc=jmattson@google.com \
--cc=kvm@vger.kernel.org \
--cc=pbonzini@redhat.com \
/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