kvm.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Vitaly Kuznetsov <vkuznets@redhat.com>
To: Paolo Bonzini <pbonzini@redhat.com>
Cc: jmattson@google.com, linux-kernel@vger.kernel.org, kvm@vger.kernel.org
Subject: Re: [PATCH 2/2] KVM: x86: synthesize CPUID leaf 0x80000021h if useful
Date: Fri, 11 Mar 2022 10:23:22 +0100	[thread overview]
Message-ID: <8735joalmd.fsf@redhat.com> (raw)
In-Reply-To: <20220309170928.1032664-3-pbonzini@redhat.com>

Paolo Bonzini <pbonzini@redhat.com> writes:

> Guests should have X86_BUG_NULL_SEG if and only if the host has the bug.
> Use the info from static_cpu_has_bug to form the 0x80000021 CPUID leaf
> that was defined for Zen3.  Userspace can then set the bit even on older
> CPUs that do not have the bug, such as Zen2.
>
> Do the same for X86_FEATURE_LFENCE_RDTSC as well, since various processors
> have had very different ways of detecting it and not all of them are
> available to userspace.
>
> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
> ---
>  arch/x86/kvm/cpuid.c | 25 +++++++++++++++++++++++++
>  1 file changed, 25 insertions(+)
>
> diff --git a/arch/x86/kvm/cpuid.c b/arch/x86/kvm/cpuid.c
> index 30832aad402f..58b0b4e0263c 100644
> --- a/arch/x86/kvm/cpuid.c
> +++ b/arch/x86/kvm/cpuid.c
> @@ -723,6 +723,19 @@ static struct kvm_cpuid_entry2 *do_host_cpuid(struct kvm_cpuid_array *array,
>  		/* Hypervisor leaves are always synthesized by __do_cpuid_func.  */
>  		return entry;
>  
> +	case 0x80000000:
> +		/*
> +		 * 0x80000021 is sometimes synthesized by __do_cpuid_func, which
> +		 * would result in out-of-bounds calls to do_host_cpuid.
> +		 */
> +		{
> +			static int max_cpuid_80000000;
> +			if (!READ_ONCE(max_cpuid_80000000))
> +				WRITE_ONCE(max_cpuid_80000000, cpuid_eax(0x80000000));
> +			if (function > READ_ONCE(max_cpuid_80000000))

Out of pure curiosity: what READ_ONCE/WRITE_ONCEs are for here?

> +				return entry;
> +		}
> +

This hunk seems to have a small side effect beyond its description:
previously, KVM_CPUID_FLAG_SIGNIFCANT_INDEX was always returned for
0x8000001d leaf, even when it wasn't present on the host. With the
change, we will return 'entry' directly from here, with no flag
set. This is likely insignificant in the absence of the leaf.


>  	default:
>  		break;
>  	}
> @@ -1069,6 +1082,14 @@ static inline int __do_cpuid_func(struct kvm_cpuid_array *array, u32 function)
>  		break;
>  	case 0x80000000:
>  		entry->eax = min(entry->eax, 0x80000021);
> +		/*
> +		 * Serializing LFENCE is reported in a multitude of ways,
> +		 * and NullSegClearsBase is not reported in CPUID on Zen2;
> +		 * help userspace by providing the CPUID leaf ourselves.
> +		 */
> +		if (static_cpu_has(X86_FEATURE_LFENCE_RDTSC)
> +		    || !static_cpu_has_bug(X86_BUG_NULL_SEG))
> +			entry->eax = max(entry->eax, 0x80000021);
>  		break;
>  	case 0x80000001:
>  		cpuid_entry_override(entry, CPUID_8000_0001_EDX);
> @@ -1155,6 +1176,10 @@ static inline int __do_cpuid_func(struct kvm_cpuid_array *array, u32 function)
>  		 *   EAX      13     PCMSR, Prefetch control MSR
>  		 */
>  		entry->eax &= BIT(0) | BIT(2) | BIT(6);
> +		if (static_cpu_has(X86_FEATURE_LFENCE_RDTSC))
> +			entry->eax |= BIT(2);
> +		if (!static_cpu_has_bug(X86_BUG_NULL_SEG))
> +			entry->eax |= BIT(6);
>  		break;
>  	/*Add support for Centaur's CPUID instruction*/
>  	case 0xC0000000:

-- 
Vitaly


      reply	other threads:[~2022-03-11  9:23 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-03-09 17:09 [PATCH 0/2] KVM: x86: add support for CPUID leaf 0x80000021 Paolo Bonzini
2022-03-09 17:09 ` [PATCH 1/2] " Paolo Bonzini
2022-03-09 17:09 ` [PATCH 2/2] KVM: x86: synthesize CPUID leaf 0x80000021h if useful Paolo Bonzini
2022-03-11  9:23   ` Vitaly Kuznetsov [this message]

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=8735joalmd.fsf@redhat.com \
    --to=vkuznets@redhat.com \
    --cc=jmattson@google.com \
    --cc=kvm@vger.kernel.org \
    --cc=linux-kernel@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;
as well as URLs for NNTP newsgroup(s).