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 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.