Re: linux-next: manual merge of the kvm-arm tree with the arm64 tree

Re: linux-next: manual merge of the kvm-arm tree with the arm64 tree

[Stephen Rothwell]

[-- Attachment #1: Type: text/plain, Size: 2109 bytes --]

Hi all,

On Wed, 28 Mar 2018 16:05:41 +1100 Stephen Rothwell <sfr@canb.auug.org.au> wrote:
>
> Today's linux-next merge of the kvm-arm tree got a conflict in:
> 
>   arch/arm64/kernel/cpufeature.c
> 
> between commits:
> 
>   143ba05d867a ("arm64: capabilities: Prepare for fine grained capabilities")
>   12eb369125ab ("arm64: cpufeature: Avoid warnings due to unused symbols")
> 
> from the arm64 tree and commit:
> 
>   a1efdff442ec ("arm64: cpufeatures: Drop the ARM64_HYP_OFFSET_LOW feature flag")
> 
> from the kvm-arm tree.
> 
> I fixed it up (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/arm64/kernel/cpufeature.c
> index 96b15d7b10a8,5b25d56bccfd..000000000000
> --- a/arch/arm64/kernel/cpufeature.c
> +++ b/arch/arm64/kernel/cpufeature.c
> @@@ -838,19 -826,11 +838,6 @@@ static bool has_no_hw_prefetch(const st
>   		MIDR_CPU_VAR_REV(1, MIDR_REVISION_MASK));
>   }
>   
> - static bool hyp_offset_low(const struct arm64_cpu_capabilities *entry,
> - 			   int __unused)
>  -static bool runs_at_el2(const struct arm64_cpu_capabilities *entry, int __unused)
> --{
> - 	phys_addr_t idmap_addr = __pa_symbol(__hyp_idmap_text_start);
> - 
> - 	/*
> - 	 * Activate the lower HYP offset only if:
> - 	 * - the idmap doesn't clash with it,
> - 	 * - the kernel is not running at EL2.
> - 	 */
> - 	return idmap_addr > GENMASK(VA_BITS - 2, 0) && !is_kernel_in_hyp_mode();
>  -	return is_kernel_in_hyp_mode();
> --}
> --
>   static bool has_no_fpsimd(const struct arm64_cpu_capabilities *entry, int __unused)
>   {
>   	u64 pfr0 = read_sanitised_ftr_reg(SYS_ID_AA64PFR0_EL1);

This is now a conflict between the kvm tree and the arm64 tree.

-- 
Cheers,
Stephen Rothwell

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

Re: linux-next: manual merge of the kvm-arm tree with the arm64 tree

[Stephen Rothwell]

[-- Attachment #1: Type: text/plain, Size: 1577 bytes --]

Hi all,

On Mon, 23 Jul 2018 14:46:41 +1000 Stephen Rothwell <sfr@canb.auug.org.au> wrote:
>
> Today's linux-next merge of the kvm-arm tree got a conflict in:
> 
>   arch/arm64/include/asm/cpucaps.h
> 
> between commit:
> 
>   314d53d29798 ("arm64: Handle mismatched cache type")
> 
> from the arm64 tree and commit:
> 
>   e48d53a91f6e ("arm64: KVM: Add support for Stage-2 control of memory types and cacheability")
> 
> from the kvm-arm tree.
> 
> I fixed it up (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/arm64/include/asm/cpucaps.h
> index be3bf3d08916,ed84d6536830..000000000000
> --- a/arch/arm64/include/asm/cpucaps.h
> +++ b/arch/arm64/include/asm/cpucaps.h
> @@@ -49,8 -49,8 +49,9 @@@
>   #define ARM64_HAS_CACHE_DIC			28
>   #define ARM64_HW_DBM				29
>   #define ARM64_SSBD				30
>  -#define ARM64_HAS_STAGE2_FWB			31
>  +#define ARM64_MISMATCHED_CACHE_TYPE		31
> ++#define ARM64_HAS_STAGE2_FWB			32
>   
> --#define ARM64_NCAPS				32
> ++#define ARM64_NCAPS				33
>   
>   #endif /* __ASM_CPUCAPS_H */

This is now a conflict between Linus' tree and the kvm-arm tree (and
presumably soon the kvm tree).

-- 
Cheers,
Stephen Rothwell

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

Re: linux-next: manual merge of the kvm-arm tree with the arm64 tree

[Paolo Bonzini]

[-- Attachment #1.1: Type: text/plain, Size: 631 bytes --]

On 16/08/2018 02:15, Stephen Rothwell wrote:
>>  -#define ARM64_HAS_STAGE2_FWB			31
>>  +#define ARM64_MISMATCHED_CACHE_TYPE		31
>> ++#define ARM64_HAS_STAGE2_FWB			32
>>   
>> --#define ARM64_NCAPS				32
>> ++#define ARM64_NCAPS				33
>>   
>>   #endif /* __ASM_CPUCAPS_H */
> This is now a conflict between Linus' tree and the kvm-arm tree (and
> presumably soon the kvm tree).

This should have been sorted out using topic branches.  I'll handle it
myself by splitting the pull request in two, but please try to organize
better the changes in non-KVM-specific arch/arm and arch/arm64 files.

Thanks,

Paolo


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

Re: linux-next: manual merge of the kvm-arm tree with the arm64 tree

[Marc Zyngier]

On Fri, 17 Aug 2018 09:32:55 +0100,
Paolo Bonzini <pbonzini@redhat.com> wrote:
> 
> On 16/08/2018 02:15, Stephen Rothwell wrote:
> >>  -#define ARM64_HAS_STAGE2_FWB			31
> >>  +#define ARM64_MISMATCHED_CACHE_TYPE		31
> >> ++#define ARM64_HAS_STAGE2_FWB			32
> >>   
> >> --#define ARM64_NCAPS				32
> >> ++#define ARM64_NCAPS				33
> >>   
> >>   #endif /* __ASM_CPUCAPS_H */
> > This is now a conflict between Linus' tree and the kvm-arm tree (and
> > presumably soon the kvm tree).
> 
> This should have been sorted out using topic branches.  I'll handle it
> myself by splitting the pull request in two, but please try to organize
> better the changes in non-KVM-specific arch/arm and arch/arm64 files.

We've dealt with that kind of trivial conflicts in the past without
requiring topic branches (cpucaps.h has always been a popular place),
and I always assumed that this was acceptable. I must have
misunderstood something here.

Next time, I'll direct the architecture-specific code via the arm64
tree directly.

Thanks,

	M.

-- 
Jazz is not dead, it just smell funny.

Re: linux-next: manual merge of the kvm-arm tree with the arm64 tree

[Stephen Rothwell]

[-- Attachment #1: Type: text/plain, Size: 5270 bytes --]

Hi all,

On Wed, 4 May 2022 14:35:29 +1000 Stephen Rothwell <sfr@canb.auug.org.au> wrote:
>
> Today's linux-next merge of the kvm-arm tree got a conflict in:
> 
>   arch/arm64/kvm/sys_regs.c
> 
> between commit:
> 
>   0b12620fddb8 ("KVM: arm64: Treat ESR_EL2 as a 64-bit register")
> 
> from the arm64 tree and commits:
> 
>   e65197666773 ("KVM: arm64: Wire up CP15 feature registers to their AArch64 equivalents")
>   9369bc5c5e35 ("KVM: arm64: Plumb cp10 ID traps through the AArch64 sysreg handler")
> 
> from the kvm-arm tree.
> 
> I fixed it up (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.
> 
> diff --cc arch/arm64/kvm/sys_regs.c
> index a4ef986adb5e,031d913cd79e..000000000000
> --- a/arch/arm64/kvm/sys_regs.c
> +++ b/arch/arm64/kvm/sys_regs.c
> @@@ -2351,6 -2355,123 +2355,123 @@@ static int kvm_handle_cp_64(struct kvm_
>   	return 1;
>   }
>   
> + static bool emulate_sys_reg(struct kvm_vcpu *vcpu, struct sys_reg_params *params);
> + 
> + /*
> +  * The CP10 ID registers are architecturally mapped to AArch64 feature
> +  * registers. Abuse that fact so we can rely on the AArch64 handler for accesses
> +  * from AArch32.
> +  */
>  -static bool kvm_esr_cp10_id_to_sys64(u32 esr, struct sys_reg_params *params)
> ++static bool kvm_esr_cp10_id_to_sys64(u64 esr, struct sys_reg_params *params)
> + {
> + 	u8 reg_id = (esr >> 10) & 0xf;
> + 	bool valid;
> + 
> + 	params->is_write = ((esr & 1) == 0);
> + 	params->Op0 = 3;
> + 	params->Op1 = 0;
> + 	params->CRn = 0;
> + 	params->CRm = 3;
> + 
> + 	/* CP10 ID registers are read-only */
> + 	valid = !params->is_write;
> + 
> + 	switch (reg_id) {
> + 	/* MVFR0 */
> + 	case 0b0111:
> + 		params->Op2 = 0;
> + 		break;
> + 	/* MVFR1 */
> + 	case 0b0110:
> + 		params->Op2 = 1;
> + 		break;
> + 	/* MVFR2 */
> + 	case 0b0101:
> + 		params->Op2 = 2;
> + 		break;
> + 	default:
> + 		valid = false;
> + 	}
> + 
> + 	if (valid)
> + 		return true;
> + 
> + 	kvm_pr_unimpl("Unhandled cp10 register %s: %u\n",
> + 		      params->is_write ? "write" : "read", reg_id);
> + 	return false;
> + }
> + 
> + /**
> +  * kvm_handle_cp10_id() - Handles a VMRS trap on guest access to a 'Media and
> +  *			  VFP Register' from AArch32.
> +  * @vcpu: The vCPU pointer
> +  *
> +  * MVFR{0-2} are architecturally mapped to the AArch64 MVFR{0-2}_EL1 registers.
> +  * Work out the correct AArch64 system register encoding and reroute to the
> +  * AArch64 system register emulation.
> +  */
> + int kvm_handle_cp10_id(struct kvm_vcpu *vcpu)
> + {
> + 	int Rt = kvm_vcpu_sys_get_rt(vcpu);
>  -	u32 esr = kvm_vcpu_get_esr(vcpu);
> ++	u64 esr = kvm_vcpu_get_esr(vcpu);
> + 	struct sys_reg_params params;
> + 
> + 	/* UNDEF on any unhandled register access */
> + 	if (!kvm_esr_cp10_id_to_sys64(esr, &params)) {
> + 		kvm_inject_undefined(vcpu);
> + 		return 1;
> + 	}
> + 
> + 	if (emulate_sys_reg(vcpu, &params))
> + 		vcpu_set_reg(vcpu, Rt, params.regval);
> + 
> + 	return 1;
> + }
> + 
> + /**
> +  * kvm_emulate_cp15_id_reg() - Handles an MRC trap on a guest CP15 access where
> +  *			       CRn=0, which corresponds to the AArch32 feature
> +  *			       registers.
> +  * @vcpu: the vCPU pointer
> +  * @params: the system register access parameters.
> +  *
> +  * Our cp15 system register tables do not enumerate the AArch32 feature
> +  * registers. Conveniently, our AArch64 table does, and the AArch32 system
> +  * register encoding can be trivially remapped into the AArch64 for the feature
> +  * registers: Append op0=3, leaving op1, CRn, CRm, and op2 the same.
> +  *
> +  * According to DDI0487G.b G7.3.1, paragraph "Behavior of VMSAv8-32 32-bit
> +  * System registers with (coproc=0b1111, CRn==c0)", read accesses from this
> +  * range are either UNKNOWN or RES0. Rerouting remains architectural as we
> +  * treat undefined registers in this range as RAZ.
> +  */
> + static int kvm_emulate_cp15_id_reg(struct kvm_vcpu *vcpu,
> + 				   struct sys_reg_params *params)
> + {
> + 	int Rt = kvm_vcpu_sys_get_rt(vcpu);
> + 
> + 	/* Treat impossible writes to RO registers as UNDEFINED */
> + 	if (params->is_write) {
> + 		unhandled_cp_access(vcpu, params);
> + 		return 1;
> + 	}
> + 
> + 	params->Op0 = 3;
> + 
> + 	/*
> + 	 * All registers where CRm > 3 are known to be UNKNOWN/RAZ from AArch32.
> + 	 * Avoid conflicting with future expansion of AArch64 feature registers
> + 	 * and simply treat them as RAZ here.
> + 	 */
> + 	if (params->CRm > 3)
> + 		params->regval = 0;
> + 	else if (!emulate_sys_reg(vcpu, params))
> + 		return 1;
> + 
> + 	vcpu_set_reg(vcpu, Rt, params->regval);
> + 	return 1;
> + }
> + 
>   /**
>    * kvm_handle_cp_32 -- handles a mrc/mcr trap on a guest CP14/CP15 access
>    * @vcpu: The VCPU pointer

This is now a conflict between the kvm tree and the arm64 tree.

-- 
Cheers,
Stephen Rothwell

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

Re: linux-next: manual merge of the kvm-arm tree with the arm64 tree

[Stephen Rothwell]

[-- Attachment #1: Type: text/plain, Size: 2834 bytes --]

Hi all,

On Thu, 15 Jun 2023 12:22:01 +1000 Stephen Rothwell <sfr@canb.auug.org.au> wrote:
> 
> Today's linux-next merge of the kvm-arm tree got a conflict in:
> 
>   arch/arm64/kernel/cpufeature.c
> 
> between commits:
> 
>   b7564127ffcb ("arm64: mops: detect and enable FEAT_MOPS")
>   2b760046a2d3 ("arm64: cpufeature: add TCR2 cpucap")
>   e43454c44232 ("arm64: cpufeature: add Permission Indirection Extension cpucap")
> 
> from the arm64 tree and commits:
> 
>   c876c3f182a5 ("KVM: arm64: Relax trapping of CTR_EL0 when FEAT_EVT is available")
>   e2d6c906f0ac ("arm64: Add KVM_HVHE capability and has_hvhe() predicate")
> 
> from the kvm-arm tree.
> 
> I fixed it up (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.
> 
> 
> diff --cc arch/arm64/kernel/cpufeature.c
> index 6ea7f23b1287,f6e3598760f1..000000000000
> --- a/arch/arm64/kernel/cpufeature.c
> +++ b/arch/arm64/kernel/cpufeature.c
> @@@ -2662,27 -2656,23 +2677,44 @@@ static const struct arm64_cpu_capabilit
>   		.cpu_enable = cpu_enable_dit,
>   		ARM64_CPUID_FIELDS(ID_AA64PFR0_EL1, DIT, IMP)
>   	},
>  +	{
>  +		.desc = "Memory Copy and Memory Set instructions",
>  +		.capability = ARM64_HAS_MOPS,
>  +		.type = ARM64_CPUCAP_SYSTEM_FEATURE,
>  +		.matches = has_cpuid_feature,
>  +		.cpu_enable = cpu_enable_mops,
>  +		ARM64_CPUID_FIELDS(ID_AA64ISAR2_EL1, MOPS, IMP)
>  +	},
>  +	{
>  +		.capability = ARM64_HAS_TCR2,
>  +		.type = ARM64_CPUCAP_SYSTEM_FEATURE,
>  +		.matches = has_cpuid_feature,
>  +		ARM64_CPUID_FIELDS(ID_AA64MMFR3_EL1, TCRX, IMP)
>  +	},
>  +	{
>  +		.desc = "Stage-1 Permission Indirection Extension (S1PIE)",
>  +		.capability = ARM64_HAS_S1PIE,
>  +		.type = ARM64_CPUCAP_BOOT_CPU_FEATURE,
>  +		.matches = has_cpuid_feature,
>  +		ARM64_CPUID_FIELDS(ID_AA64MMFR3_EL1, S1PIE, IMP)
>  +	},
> + 	{
> + 		.desc = "Enhanced Virtualization Traps",
> + 		.capability = ARM64_HAS_EVT,
> + 		.type = ARM64_CPUCAP_SYSTEM_FEATURE,
> + 		.sys_reg = SYS_ID_AA64MMFR2_EL1,
> + 		.sign = FTR_UNSIGNED,
> + 		.field_pos = ID_AA64MMFR2_EL1_EVT_SHIFT,
> + 		.field_width = 4,
> + 		.min_field_value = ID_AA64MMFR2_EL1_EVT_IMP,
> + 		.matches = has_cpuid_feature,
> + 	},
> + 	{
> + 		.desc = "VHE for hypervisor only",
> + 		.capability = ARM64_KVM_HVHE,
> + 		.type = ARM64_CPUCAP_SYSTEM_FEATURE,
> + 		.matches = hvhe_possible,
> + 	},
>   	{},
>   };
>   

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

Re: linux-next: manual merge of the kvm-arm tree with the arm64 tree

[Stephen Rothwell]

[-- Attachment #1: Type: text/plain, Size: 957 bytes --]

Hi all,

On Tue, 17 Oct 2023 12:30:17 +1100 Stephen Rothwell <sfr@canb.auug.org.au> wrote:
>
> Today's linux-next merge of the kvm-arm tree got a conflict in:
> 
>   arch/arm64/kvm/arm.c
> 
> between commit:
> 
>   d8569fba1385 ("arm64: kvm: Use cpus_have_final_cap() explicitly")
> 
> from the arm64 tree and commit:
> 
>   ef150908b6bd ("KVM: arm64: Add generic check for system-supported vCPU features")
> 
> from the kvm-arm tree.
> 
> I fixed it up (I just used the latter) 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.

This is now a conflict between the kvm tree and the arm64 tree.

-- 
Cheers,
Stephen Rothwell

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

Re: linux-next: manual merge of the kvm-arm tree with the arm64 tree

[Stephen Rothwell]

[-- Attachment #1: Type: text/plain, Size: 978 bytes --]

Hi all,

On Thu, 31 Oct 2024 14:35:19 +1100 Stephen Rothwell <sfr@canb.auug.org.au> wrote:
>
> Today's linux-next merge of the kvm-arm tree got a conflict in:
> 
>   arch/arm64/tools/sysreg
> 
> between commit:
> 
>   034993461890 ("arm64/sysreg: Update ID_AA64MMFR1_EL1 to DDI0601 2024-09")
> 
> from the arm64 tree and commit:
> 
>   9ae424d2a1ae ("arm64: Define ID_AA64MMFR1_EL1.HAFDBS advertising FEAT_HAFT")
> 
> from the kvm-arm tree.
> 
> I fixed it up (the former is a superset of the latter) 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.

This is now a conflict between the kvm tree and the arm64 tree

-- 
Cheers,
Stephen Rothwell

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

Re: linux-next: manual merge of the kvm-arm tree with the arm64 tree

[Stephen Rothwell]

[-- Attachment #1: Type: text/plain, Size: 6206 bytes --]

Hi all,

On Mon, 17 Mar 2025 17:17:01 +1100 Stephen Rothwell <sfr@canb.auug.org.au> wrote:
> 
> Today's linux-next merge of the kvm-arm tree got a conflict in:
> 
>   arch/arm64/kernel/proton-pack.c
> 
> between commits:
> 
>   e403e8538359 ("arm64: errata: Assume that unknown CPUs _are_ vulnerable to Spectre BHB")
>   a5951389e58d ("arm64: errata: Add newer ARM cores to the spectre_bhb_loop_affected() lists")
> 
> from the arm64 tree and commit:
> 
>   e3121298c7fc ("arm64: Modify _midr_range() functions to read MIDR/REVIDR internally")
> 
> from the kvm-arm tree.
> 
> I fixed it up (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.
> 
> 
> diff --cc arch/arm64/kernel/proton-pack.c
> index 0f51fd10b4b0,a573fa40d4b6..000000000000
> --- a/arch/arm64/kernel/proton-pack.c
> +++ b/arch/arm64/kernel/proton-pack.c
> @@@ -845,86 -845,52 +845,86 @@@ static unsigned long system_bhb_mitigat
>    * This must be called with SCOPE_LOCAL_CPU for each type of CPU, before any
>    * SCOPE_SYSTEM call will give the right answer.
>    */
>  -u8 spectre_bhb_loop_affected(int scope)
>  +static bool is_spectre_bhb_safe(int scope)
>  +{
>  +	static const struct midr_range spectre_bhb_safe_list[] = {
>  +		MIDR_ALL_VERSIONS(MIDR_CORTEX_A35),
>  +		MIDR_ALL_VERSIONS(MIDR_CORTEX_A53),
>  +		MIDR_ALL_VERSIONS(MIDR_CORTEX_A55),
>  +		MIDR_ALL_VERSIONS(MIDR_CORTEX_A510),
>  +		MIDR_ALL_VERSIONS(MIDR_CORTEX_A520),
>  +		MIDR_ALL_VERSIONS(MIDR_BRAHMA_B53),
>  +		MIDR_ALL_VERSIONS(MIDR_QCOM_KRYO_2XX_SILVER),
>  +		MIDR_ALL_VERSIONS(MIDR_QCOM_KRYO_3XX_SILVER),
>  +		MIDR_ALL_VERSIONS(MIDR_QCOM_KRYO_4XX_SILVER),
>  +		{},
>  +	};
>  +	static bool all_safe = true;
>  +
>  +	if (scope != SCOPE_LOCAL_CPU)
>  +		return all_safe;
>  +
> - 	if (is_midr_in_range_list(read_cpuid_id(), spectre_bhb_safe_list))
> ++	if (is_midr_in_range_list(spectre_bhb_safe_list))
>  +		return true;
>  +
>  +	all_safe = false;
>  +
>  +	return false;
>  +}
>  +
>  +static u8 spectre_bhb_loop_affected(void)
>   {
>   	u8 k = 0;
>  -	static u8 max_bhb_k;
>   
>  -	if (scope == SCOPE_LOCAL_CPU) {
>  -		static const struct midr_range spectre_bhb_k32_list[] = {
>  -			MIDR_ALL_VERSIONS(MIDR_CORTEX_A78),
>  -			MIDR_ALL_VERSIONS(MIDR_CORTEX_A78AE),
>  -			MIDR_ALL_VERSIONS(MIDR_CORTEX_A78C),
>  -			MIDR_ALL_VERSIONS(MIDR_CORTEX_X1),
>  -			MIDR_ALL_VERSIONS(MIDR_CORTEX_A710),
>  -			MIDR_ALL_VERSIONS(MIDR_CORTEX_X2),
>  -			MIDR_ALL_VERSIONS(MIDR_NEOVERSE_N2),
>  -			MIDR_ALL_VERSIONS(MIDR_NEOVERSE_V1),
>  -			{},
>  -		};
>  -		static const struct midr_range spectre_bhb_k24_list[] = {
>  -			MIDR_ALL_VERSIONS(MIDR_CORTEX_A76),
>  -			MIDR_ALL_VERSIONS(MIDR_CORTEX_A77),
>  -			MIDR_ALL_VERSIONS(MIDR_NEOVERSE_N1),
>  -			{},
>  -		};
>  -		static const struct midr_range spectre_bhb_k11_list[] = {
>  -			MIDR_ALL_VERSIONS(MIDR_AMPERE1),
>  -			{},
>  -		};
>  -		static const struct midr_range spectre_bhb_k8_list[] = {
>  -			MIDR_ALL_VERSIONS(MIDR_CORTEX_A72),
>  -			MIDR_ALL_VERSIONS(MIDR_CORTEX_A57),
>  -			{},
>  -		};
>  +	static const struct midr_range spectre_bhb_k132_list[] = {
>  +		MIDR_ALL_VERSIONS(MIDR_CORTEX_X3),
>  +		MIDR_ALL_VERSIONS(MIDR_NEOVERSE_V2),
>  +	};
>  +	static const struct midr_range spectre_bhb_k38_list[] = {
>  +		MIDR_ALL_VERSIONS(MIDR_CORTEX_A715),
>  +		MIDR_ALL_VERSIONS(MIDR_CORTEX_A720),
>  +	};
>  +	static const struct midr_range spectre_bhb_k32_list[] = {
>  +		MIDR_ALL_VERSIONS(MIDR_CORTEX_A78),
>  +		MIDR_ALL_VERSIONS(MIDR_CORTEX_A78AE),
>  +		MIDR_ALL_VERSIONS(MIDR_CORTEX_A78C),
>  +		MIDR_ALL_VERSIONS(MIDR_CORTEX_X1),
>  +		MIDR_ALL_VERSIONS(MIDR_CORTEX_A710),
>  +		MIDR_ALL_VERSIONS(MIDR_CORTEX_X2),
>  +		MIDR_ALL_VERSIONS(MIDR_NEOVERSE_N2),
>  +		MIDR_ALL_VERSIONS(MIDR_NEOVERSE_V1),
>  +		{},
>  +	};
>  +	static const struct midr_range spectre_bhb_k24_list[] = {
>  +		MIDR_ALL_VERSIONS(MIDR_CORTEX_A76),
>  +		MIDR_ALL_VERSIONS(MIDR_CORTEX_A76AE),
>  +		MIDR_ALL_VERSIONS(MIDR_CORTEX_A77),
>  +		MIDR_ALL_VERSIONS(MIDR_NEOVERSE_N1),
>  +		MIDR_ALL_VERSIONS(MIDR_QCOM_KRYO_4XX_GOLD),
>  +		{},
>  +	};
>  +	static const struct midr_range spectre_bhb_k11_list[] = {
>  +		MIDR_ALL_VERSIONS(MIDR_AMPERE1),
>  +		{},
>  +	};
>  +	static const struct midr_range spectre_bhb_k8_list[] = {
>  +		MIDR_ALL_VERSIONS(MIDR_CORTEX_A72),
>  +		MIDR_ALL_VERSIONS(MIDR_CORTEX_A57),
>  +		{},
>  +	};
>   
> - 	if (is_midr_in_range_list(read_cpuid_id(), spectre_bhb_k132_list))
>  -		if (is_midr_in_range_list(spectre_bhb_k32_list))
>  -			k = 32;
>  -		else if (is_midr_in_range_list(spectre_bhb_k24_list))
>  -			k = 24;
>  -		else if (is_midr_in_range_list(spectre_bhb_k11_list))
>  -			k = 11;
>  -		else if (is_midr_in_range_list(spectre_bhb_k8_list))
>  -			k =  8;
>  -
>  -		max_bhb_k = max(max_bhb_k, k);
>  -	} else {
>  -		k = max_bhb_k;
>  -	}
> ++	if (is_midr_in_range_list(spectre_bhb_k132_list))
>  +		k = 132;
> - 	else if (is_midr_in_range_list(read_cpuid_id(), spectre_bhb_k38_list))
> ++	else if (is_midr_in_range_list(spectre_bhb_k38_list))
>  +		k = 38;
> - 	else if (is_midr_in_range_list(read_cpuid_id(), spectre_bhb_k32_list))
> ++	else if (is_midr_in_range_list(spectre_bhb_k32_list))
>  +		k = 32;
> - 	else if (is_midr_in_range_list(read_cpuid_id(), spectre_bhb_k24_list))
> ++	else if (is_midr_in_range_list(spectre_bhb_k24_list))
>  +		k = 24;
> - 	else if (is_midr_in_range_list(read_cpuid_id(), spectre_bhb_k11_list))
> ++	else if (is_midr_in_range_list(spectre_bhb_k11_list))
>  +		k = 11;
> - 	else if (is_midr_in_range_list(read_cpuid_id(), spectre_bhb_k8_list))
> ++	else if (is_midr_in_range_list(spectre_bhb_k8_list))
>  +		k =  8;
>   
>   	return k;
>   }

This is now a conflict between the kvm tree and the arm64 tree.

-- 
Cheers,
Stephen Rothwell

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]