| lists.openwall.net | lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC | |
|
Open Source and information security mailing list archives
| ||
|
Message-ID: <20250123142553.12c76c11@canb.auug.org.au>
Date: Thu, 23 Jan 2025 14:25:53 +1100
From: Stephen Rothwell <sfr@...b.auug.org.au>
To: Paolo Bonzini <pbonzini@...hat.com>
Cc: Sean Christopherson <seanjc@...gle.com>, Thomas Gleixner
<tglx@...utronix.de>, Ingo Molnar <mingo@...hat.com>, "H. Peter Anvin"
<hpa@...or.com>, Peter Zijlstra <peterz@...radead.org>, "Borislav Petkov
(AMD)" <bp@...en8.de>, Linux Kernel Mailing List
<linux-kernel@...r.kernel.org>, Linux Next Mailing List
<linux-next@...r.kernel.org>, KVM <kvm@...r.kernel.org>
Subject: Re: linux-next: manual merge of the kvm-x86 tree with the tip tree
Hi all,
On Mon, 6 Jan 2025 15:05:09 +1100 Stephen Rothwell <sfr@...b.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
Content of type "application/pgp-signature" skipped
Powered by blists - more mailing lists