From: Stephen Rothwell <sfr@canb•auug.org.au>
To: Paolo Bonzini <pbonzini@redhat•com>
Cc: Sean Christopherson <seanjc@google•com>,
Thomas Gleixner <tglx@linutronix•de>,
Ingo Molnar <mingo@redhat•com>, "H. Peter Anvin" <hpa@zytor•com>,
Peter Zijlstra <peterz@infradead•org>,
"Borislav Petkov (AMD)" <bp@alien8•de>,
Linux Kernel Mailing List <linux-kernel@vger•kernel.org>,
Linux Next Mailing List <linux-next@vger•kernel.org>,
KVM <kvm@vger•kernel.org>
Subject: Re: linux-next: manual merge of the kvm-x86 tree with the tip tree
Date: Thu, 23 Jan 2025 14:25:53 +1100 [thread overview]
Message-ID: <20250123142553.12c76c11@canb.auug.org.au> (raw)
In-Reply-To: <20250106150509.19432acd@canb.auug.org.au>
[-- Attachment #1: Type: text/plain, Size: 5445 bytes --]
Hi all,
On Mon, 6 Jan 2025 15:05:09 +1100 Stephen Rothwell <sfr@canb•auug.org.au> wrote:
>
> Today's linux-next merge of the kvm-x86 tree got a conflict in:
>
> arch/x86/kvm/cpuid.c
>
> between commit:
>
> 716f86b523d8 ("KVM: x86: Advertise SRSO_USER_KERNEL_NO to userspace")
>
> from the tip tree and commits:
>
> ccf93de484a3 ("KVM: x86: Unpack F() CPUID feature flag macros to one flag per line of code")
> 3cc359ca29ad ("KVM: x86: Rename kvm_cpu_cap_mask() to kvm_cpu_cap_init()")
> 75c489e12d4b ("KVM: x86: Add a macro for features that are synthesized into boot_cpu_data")
> 871ac338ef55 ("KVM: x86: Use only local variables (no bitmask) to init kvm_cpu_caps")
>
> from the kvm-x86 tree.
>
> I fixed it up (I think - see below) and can carry the fix as
> necessary. This is now fixed as far as linux-next is concerned, but any
> non trivial conflicts should be mentioned to your upstream maintainer
> when your tree is submitted for merging. You may also want to consider
> cooperating with the maintainer of the conflicting tree to minimise any
> particularly complex conflicts.
>
> --
> Cheers,
> Stephen Rothwell
>
> diff --cc arch/x86/kvm/cpuid.c
> index f7e222953cab,edef30359c19..000000000000
> --- a/arch/x86/kvm/cpuid.c
> +++ b/arch/x86/kvm/cpuid.c
> @@@ -808,50 -1134,72 +1134,73 @@@ void kvm_set_cpu_caps(void
> !boot_cpu_has(X86_FEATURE_AMD_SSBD))
> kvm_cpu_cap_set(X86_FEATURE_VIRT_SSBD);
>
> - /*
> - * Hide all SVM features by default, SVM will set the cap bits for
> - * features it emulates and/or exposes for L1.
> - */
> - kvm_cpu_cap_mask(CPUID_8000_000A_EDX, 0);
> -
> - kvm_cpu_cap_mask(CPUID_8000_001F_EAX,
> - 0 /* SME */ | 0 /* SEV */ | 0 /* VM_PAGE_FLUSH */ | 0 /* SEV_ES */ |
> - F(SME_COHERENT));
> -
> - kvm_cpu_cap_mask(CPUID_8000_0021_EAX,
> - F(NO_NESTED_DATA_BP) | F(LFENCE_RDTSC) | 0 /* SmmPgCfgLock */ |
> - F(NULL_SEL_CLR_BASE) | F(AUTOIBRS) | 0 /* PrefetchCtlMsr */ |
> - F(WRMSR_XX_BASE_NS) | F(SRSO_USER_KERNEL_NO)
> + /* All SVM features required additional vendor module enabling. */
> + kvm_cpu_cap_init(CPUID_8000_000A_EDX,
> + VENDOR_F(NPT),
> + VENDOR_F(VMCBCLEAN),
> + VENDOR_F(FLUSHBYASID),
> + VENDOR_F(NRIPS),
> + VENDOR_F(TSCRATEMSR),
> + VENDOR_F(V_VMSAVE_VMLOAD),
> + VENDOR_F(LBRV),
> + VENDOR_F(PAUSEFILTER),
> + VENDOR_F(PFTHRESHOLD),
> + VENDOR_F(VGIF),
> + VENDOR_F(VNMI),
> + VENDOR_F(SVME_ADDR_CHK),
> );
>
> - kvm_cpu_cap_check_and_set(X86_FEATURE_SBPB);
> - kvm_cpu_cap_check_and_set(X86_FEATURE_IBPB_BRTYPE);
> - kvm_cpu_cap_check_and_set(X86_FEATURE_SRSO_NO);
> -
> - kvm_cpu_cap_init_kvm_defined(CPUID_8000_0022_EAX,
> - F(PERFMON_V2)
> + kvm_cpu_cap_init(CPUID_8000_001F_EAX,
> + VENDOR_F(SME),
> + VENDOR_F(SEV),
> + /* VM_PAGE_FLUSH */
> + VENDOR_F(SEV_ES),
> + F(SME_COHERENT),
> + );
> +
> + kvm_cpu_cap_init(CPUID_8000_0021_EAX,
> + F(NO_NESTED_DATA_BP),
> + /*
> + * Synthesize "LFENCE is serializing" into the AMD-defined entry
> + * in KVM's supported CPUID, i.e. if the feature is reported as
> + * supported by the kernel. LFENCE_RDTSC was a Linux-defined
> + * synthetic feature long before AMD joined the bandwagon, e.g.
> + * LFENCE is serializing on most CPUs that support SSE2. On
> + * CPUs that don't support AMD's leaf, ANDing with the raw host
> + * CPUID will drop the flags, and reporting support in AMD's
> + * leaf can make it easier for userspace to detect the feature.
> + */
> + SYNTHESIZED_F(LFENCE_RDTSC),
> + /* SmmPgCfgLock */
> + F(NULL_SEL_CLR_BASE),
> + F(AUTOIBRS),
> + EMULATED_F(NO_SMM_CTL_MSR),
> + /* PrefetchCtlMsr */
> + F(WRMSR_XX_BASE_NS),
> ++ F(SRSO_USER_KERNEL_NO),
> + SYNTHESIZED_F(SBPB),
> + SYNTHESIZED_F(IBPB_BRTYPE),
> + SYNTHESIZED_F(SRSO_NO),
> + );
> +
> + kvm_cpu_cap_init(CPUID_8000_0022_EAX,
> + F(PERFMON_V2),
> );
>
> - /*
> - * Synthesize "LFENCE is serializing" into the AMD-defined entry in
> - * KVM's supported CPUID if the feature is reported as supported by the
> - * kernel. LFENCE_RDTSC was a Linux-defined synthetic feature long
> - * before AMD joined the bandwagon, e.g. LFENCE is serializing on most
> - * CPUs that support SSE2. On CPUs that don't support AMD's leaf,
> - * kvm_cpu_cap_mask() will unfortunately drop the flag due to ANDing
> - * the mask with the raw host CPUID, and reporting support in AMD's
> - * leaf can make it easier for userspace to detect the feature.
> - */
> - if (cpu_feature_enabled(X86_FEATURE_LFENCE_RDTSC))
> - kvm_cpu_cap_set(X86_FEATURE_LFENCE_RDTSC);
> if (!static_cpu_has_bug(X86_BUG_NULL_SEG))
> kvm_cpu_cap_set(X86_FEATURE_NULL_SEL_CLR_BASE);
> - kvm_cpu_cap_set(X86_FEATURE_NO_SMM_CTL_MSR);
>
> - kvm_cpu_cap_mask(CPUID_C000_0001_EDX,
> - F(XSTORE) | F(XSTORE_EN) | F(XCRYPT) | F(XCRYPT_EN) |
> - F(ACE2) | F(ACE2_EN) | F(PHE) | F(PHE_EN) |
> - F(PMM) | F(PMM_EN)
> + kvm_cpu_cap_init(CPUID_C000_0001_EDX,
> + F(XSTORE),
> + F(XSTORE_EN),
> + F(XCRYPT),
> + F(XCRYPT_EN),
> + F(ACE2),
> + F(ACE2_EN),
> + F(PHE),
> + F(PHE_EN),
> + F(PMM),
> + F(PMM_EN),
> );
>
> /*
This is now a conflict between the kvm tree and Linus' tree.
--
Cheers,
Stephen Rothwell
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
next prev parent reply other threads:[~2025-01-23 3:26 UTC|newest]
Thread overview: 25+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-01-06 4:05 linux-next: manual merge of the kvm-x86 tree with the tip tree Stephen Rothwell
2025-01-09 19:18 ` Sean Christopherson
2025-01-23 3:25 ` Stephen Rothwell [this message]
-- strict thread matches above, loose matches on Subject: below --
2026-05-27 14:22 Mark Brown
2026-05-18 16:10 Mark Brown
2026-03-04 12:21 Mark Brown
2026-03-04 23:10 ` Sean Christopherson
2026-03-05 19:24 ` Nathan Chancellor
2026-03-06 13:24 ` Mark Brown
2026-03-06 22:48 ` Nathan Chancellor
2025-11-25 4:59 Stephen Rothwell
2025-11-25 7:09 ` Borislav Petkov
2025-12-04 5:10 ` Stephen Rothwell
2025-11-20 4:52 Stephen Rothwell
2025-11-20 4:46 Stephen Rothwell
2025-10-20 0:07 Stephen Rothwell
2025-09-22 9:50 Mark Brown
2025-09-22 11:27 ` Aithal, Srikanth
2025-09-22 11:40 ` Mark Brown
2025-09-22 13:23 ` Mark Brown
2025-09-22 14:04 ` Sean Christopherson
2025-09-30 18:13 ` Paolo Bonzini
2025-09-19 13:50 Mark Brown
2024-02-07 4:35 Stephen Rothwell
2023-01-19 23:54 Stephen Rothwell
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=20250123142553.12c76c11@canb.auug.org.au \
--to=sfr@canb$(echo .)auug.org.au \
--cc=bp@alien8$(echo .)de \
--cc=hpa@zytor$(echo .)com \
--cc=kvm@vger$(echo .)kernel.org \
--cc=linux-kernel@vger$(echo .)kernel.org \
--cc=linux-next@vger$(echo .)kernel.org \
--cc=mingo@redhat$(echo .)com \
--cc=pbonzini@redhat$(echo .)com \
--cc=peterz@infradead$(echo .)org \
--cc=seanjc@google$(echo .)com \
--cc=tglx@linutronix$(echo .)de \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
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