linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
* linux-next: manual merge of the kvm-arm tree with the arm64 tree
@ 2018-03-28  5:00 Stephen Rothwell
  2018-03-28 11:53 ` Will Deacon
  0 siblings, 1 reply; 83+ messages in thread
From: Stephen Rothwell @ 2018-03-28  5:00 UTC (permalink / raw)
  To: Christoffer Dall, Marc Zyngier, Catalin Marinas, Will Deacon
  Cc: Linux-Next Mailing List, Linux Kernel Mailing List,
	Shanker Donthineni, Dave Martin, Suzuki K Poulose

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

Hi all,

Today's linux-next merge of the kvm-arm tree got a conflict in:

  arch/arm64/kernel/cpu_errata.c

between commit:

  c0cda3b8ee6b ("arm64: capabilities: Update prototype for enable call back")
  followed by a series of patches cleaning up capabilities

from the arm64 tree and commits:

  4b472ffd1513 ("arm64: Enable ARM64_HARDEN_EL2_VECTORS on Cortex-A57 and A72")
  f9f5dc19509b ("arm64: KVM: Use SMCCC_ARCH_WORKAROUND_1 for Falkor BP hardening")

from the kvm-arm tree.

I fixed it up (maybe, please check the result and 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/cpu_errata.c
index 2df792771053,caa73af7d26e..000000000000
--- a/arch/arm64/kernel/cpu_errata.c
+++ b/arch/arm64/kernel/cpu_errata.c
@@@ -76,8 -57,11 +76,10 @@@ cpu_enable_trap_ctr_access(const struc
  {
  	/* Clear SCTLR_EL1.UCT */
  	config_sctlr_el1(SCTLR_EL1_UCT, 0);
 -	return 0;
  }
  
+ atomic_t arm64_el2_vector_last_slot = ATOMIC_INIT(-1);
+ 
  #ifdef CONFIG_HARDEN_BRANCH_PREDICTOR
  #include <asm/mmu_context.h>
  #include <asm/cacheflush.h>
@@@ -179,18 -156,31 +174,31 @@@ static void call_hvc_arch_workaround_1(
  	arm_smccc_1_1_hvc(ARM_SMCCC_ARCH_WORKAROUND_1, NULL);
  }
  
+ static void qcom_link_stack_sanitization(void)
+ {
+ 	u64 tmp;
+ 
+ 	asm volatile("mov	%0, x30		\n"
+ 		     ".rept	16		\n"
+ 		     "bl	. + 4		\n"
+ 		     ".endr			\n"
+ 		     "mov	x30, %0		\n"
+ 		     : "=&r" (tmp));
+ }
+ 
 -static int enable_smccc_arch_workaround_1(void *data)
 +static void
 +enable_smccc_arch_workaround_1(const struct arm64_cpu_capabilities *entry)
  {
 -	const struct arm64_cpu_capabilities *entry = data;
  	bp_hardening_cb_t cb;
  	void *smccc_start, *smccc_end;
  	struct arm_smccc_res res;
+ 	u32 midr = read_cpuid_id();
  
  	if (!entry->matches(entry, SCOPE_LOCAL_CPU))
 -		return 0;
 +		return;
  
  	if (psci_ops.smccc_version == SMCCC_VERSION_1_0)
 -		return 0;
 +		return;
  
  	switch (psci_ops.conduit) {
  	case PSCI_CONDUIT_HVC:
@@@ -214,139 -204,33 +222,124 @@@
  		break;
  
  	default:
 -		return 0;
 +		return;
  	}
  
+ 	if (((midr & MIDR_CPU_MODEL_MASK) == MIDR_QCOM_FALKOR) ||
+ 	    ((midr & MIDR_CPU_MODEL_MASK) == MIDR_QCOM_FALKOR_V1))
+ 		cb = qcom_link_stack_sanitization;
+ 
  	install_bp_hardening_cb(entry, cb, smccc_start, smccc_end);
  
 -	return 0;
 +	return;
  }
  
- static void qcom_link_stack_sanitization(void)
- {
- 	u64 tmp;
- 
- 	asm volatile("mov	%0, x30		\n"
- 		     ".rept	16		\n"
- 		     "bl	. + 4		\n"
- 		     ".endr			\n"
- 		     "mov	x30, %0		\n"
- 		     : "=&r" (tmp));
- }
- 
- static void
- qcom_enable_link_stack_sanitization(const struct arm64_cpu_capabilities *entry)
- {
- 	install_bp_hardening_cb(entry, qcom_link_stack_sanitization,
- 				__qcom_hyp_sanitize_link_stack_start,
- 				__qcom_hyp_sanitize_link_stack_end);
- }
  #endif	/* CONFIG_HARDEN_BRANCH_PREDICTOR */
  
 -#define MIDR_RANGE(model, min, max) \
 -	.def_scope = SCOPE_LOCAL_CPU, \
 -	.matches = is_affected_midr_range, \
 -	.midr_model = model, \
 -	.midr_range_min = min, \
 -	.midr_range_max = max
 +#define CAP_MIDR_RANGE(model, v_min, r_min, v_max, r_max)	\
 +	.matches = is_affected_midr_range,			\
 +	.midr_range = MIDR_RANGE(model, v_min, r_min, v_max, r_max)
 +
 +#define CAP_MIDR_ALL_VERSIONS(model)					\
 +	.matches = is_affected_midr_range,				\
 +	.midr_range = MIDR_ALL_VERSIONS(model)
 +
 +#define MIDR_FIXED(rev, revidr_mask) \
 +	.fixed_revs = (struct arm64_midr_revidr[]){{ (rev), (revidr_mask) }, {}}
 +
 +#define ERRATA_MIDR_RANGE(model, v_min, r_min, v_max, r_max)		\
 +	.type = ARM64_CPUCAP_LOCAL_CPU_ERRATUM,				\
 +	CAP_MIDR_RANGE(model, v_min, r_min, v_max, r_max)
 +
 +#define CAP_MIDR_RANGE_LIST(list)				\
 +	.matches = is_affected_midr_range_list,			\
 +	.midr_range_list = list
 +
 +/* Errata affecting a range of revisions of  given model variant */
 +#define ERRATA_MIDR_REV_RANGE(m, var, r_min, r_max)	 \
 +	ERRATA_MIDR_RANGE(m, var, r_min, var, r_max)
 +
 +/* Errata affecting a single variant/revision of a model */
 +#define ERRATA_MIDR_REV(model, var, rev)	\
 +	ERRATA_MIDR_RANGE(model, var, rev, var, rev)
 +
 +/* Errata affecting all variants/revisions of a given a model */
 +#define ERRATA_MIDR_ALL_VERSIONS(model)				\
 +	.type = ARM64_CPUCAP_LOCAL_CPU_ERRATUM,			\
 +	CAP_MIDR_ALL_VERSIONS(model)
 +
 +/* Errata affecting a list of midr ranges, with same work around */
 +#define ERRATA_MIDR_RANGE_LIST(midr_list)			\
 +	.type = ARM64_CPUCAP_LOCAL_CPU_ERRATUM,			\
 +	CAP_MIDR_RANGE_LIST(midr_list)
 +
 +/*
 + * Generic helper for handling capabilties with multiple (match,enable) pairs
 + * of call backs, sharing the same capability bit.
 + * Iterate over each entry to see if at least one matches.
 + */
 +static bool __maybe_unused
 +multi_entry_cap_matches(const struct arm64_cpu_capabilities *entry, int scope)
 +{
 +	const struct arm64_cpu_capabilities *caps;
 +
 +	for (caps = entry->match_list; caps->matches; caps++)
 +		if (caps->matches(caps, scope))
 +			return true;
 +
 +	return false;
 +}
 +
 +/*
 + * Take appropriate action for all matching entries in the shared capability
 + * entry.
 + */
 +static void __maybe_unused
 +multi_entry_cap_cpu_enable(const struct arm64_cpu_capabilities *entry)
 +{
 +	const struct arm64_cpu_capabilities *caps;
 +
 +	for (caps = entry->match_list; caps->matches; caps++)
 +		if (caps->matches(caps, SCOPE_LOCAL_CPU) &&
 +		    caps->cpu_enable)
 +			caps->cpu_enable(caps);
 +}
 +
 +#ifdef CONFIG_HARDEN_BRANCH_PREDICTOR
 +
 +/*
 + * List of CPUs where we need to issue a psci call to
 + * harden the branch predictor.
 + */
 +static const struct midr_range arm64_bp_harden_smccc_cpus[] = {
 +	MIDR_ALL_VERSIONS(MIDR_CORTEX_A57),
 +	MIDR_ALL_VERSIONS(MIDR_CORTEX_A72),
 +	MIDR_ALL_VERSIONS(MIDR_CORTEX_A73),
 +	MIDR_ALL_VERSIONS(MIDR_CORTEX_A75),
 +	MIDR_ALL_VERSIONS(MIDR_BRCM_VULCAN),
 +	MIDR_ALL_VERSIONS(MIDR_CAVIUM_THUNDERX2),
 +	{},
 +};
 +
 +static const struct midr_range qcom_bp_harden_cpus[] = {
 +	MIDR_ALL_VERSIONS(MIDR_QCOM_FALKOR_V1),
 +	MIDR_ALL_VERSIONS(MIDR_QCOM_FALKOR),
 +	{},
 +};
 +
 +static const struct arm64_cpu_capabilities arm64_bp_harden_list[] = {
 +	{
 +		CAP_MIDR_RANGE_LIST(arm64_bp_harden_smccc_cpus),
 +		.cpu_enable = enable_smccc_arch_workaround_1,
 +	},
 +	{
 +		CAP_MIDR_RANGE_LIST(qcom_bp_harden_cpus),
 +		.cpu_enable = qcom_enable_link_stack_sanitization,
 +	},
 +	{},
 +};
  
 -#define MIDR_ALL_VERSIONS(model) \
 -	.def_scope = SCOPE_LOCAL_CPU, \
 -	.matches = is_affected_midr_range, \
 -	.midr_model = model, \
 -	.midr_range_min = 0, \
 -	.midr_range_max = (MIDR_VARIANT_MASK | MIDR_REVISION_MASK)
 +#endif
  
  const struct arm64_cpu_capabilities arm64_errata[] = {
  #if	defined(CONFIG_ARM64_ERRATUM_826319) || \
@@@ -491,15 -369,56 +484,27 @@@
  #ifdef CONFIG_HARDEN_BRANCH_PREDICTOR
  	{
  		.capability = ARM64_HARDEN_BRANCH_PREDICTOR,
 -		MIDR_ALL_VERSIONS(MIDR_CORTEX_A57),
 -		.enable = enable_smccc_arch_workaround_1,
 -	},
 -	{
 -		.capability = ARM64_HARDEN_BRANCH_PREDICTOR,
 -		MIDR_ALL_VERSIONS(MIDR_CORTEX_A72),
 -		.enable = enable_smccc_arch_workaround_1,
 -	},
 -	{
 -		.capability = ARM64_HARDEN_BRANCH_PREDICTOR,
 -		MIDR_ALL_VERSIONS(MIDR_CORTEX_A73),
 -		.enable = enable_smccc_arch_workaround_1,
 -	},
 -	{
 -		.capability = ARM64_HARDEN_BRANCH_PREDICTOR,
 -		MIDR_ALL_VERSIONS(MIDR_CORTEX_A75),
 -		.enable = enable_smccc_arch_workaround_1,
 -	},
 -	{
 -		.capability = ARM64_HARDEN_BRANCH_PREDICTOR,
 -		MIDR_ALL_VERSIONS(MIDR_QCOM_FALKOR_V1),
 -		.enable = enable_smccc_arch_workaround_1,
 -	},
 -	{
 -		.capability = ARM64_HARDEN_BRANCH_PREDICTOR,
 -		MIDR_ALL_VERSIONS(MIDR_QCOM_FALKOR),
 -		.enable = enable_smccc_arch_workaround_1,
 +		.type = ARM64_CPUCAP_LOCAL_CPU_ERRATUM,
 +		.matches = multi_entry_cap_matches,
 +		.cpu_enable = multi_entry_cap_cpu_enable,
 +		.match_list = arm64_bp_harden_list,
  	},
  	{
 -		.capability = ARM64_HARDEN_BRANCH_PREDICTOR,
 -		MIDR_ALL_VERSIONS(MIDR_BRCM_VULCAN),
 -		.enable = enable_smccc_arch_workaround_1,
 -	},
 -	{
 -		.capability = ARM64_HARDEN_BRANCH_PREDICTOR,
 -		MIDR_ALL_VERSIONS(MIDR_CAVIUM_THUNDERX2),
 -		.enable = enable_smccc_arch_workaround_1,
 +		.capability = ARM64_HARDEN_BP_POST_GUEST_EXIT,
 +		ERRATA_MIDR_RANGE_LIST(qcom_bp_harden_cpus),
  	},
+ #endif
+ #ifdef CONFIG_HARDEN_EL2_VECTORS
+ 	{
+ 		.desc = "Cortex-A57 EL2 vector hardening",
+ 		.capability = ARM64_HARDEN_EL2_VECTORS,
 -		MIDR_ALL_VERSIONS(MIDR_CORTEX_A57),
++		ERRATA_MIDR_ALL_VERSIONS(MIDR_CORTEX_A57),
+ 	},
+ 	{
+ 		.desc = "Cortex-A72 EL2 vector hardening",
+ 		.capability = ARM64_HARDEN_EL2_VECTORS,
 -		MIDR_ALL_VERSIONS(MIDR_CORTEX_A72),
++		ERRATA_MIDR_ALL_VERSIONS(MIDR_CORTEX_A72),
+ 	},
  #endif
  	{
  	}

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

^ permalink raw reply	[flat|nested] 83+ messages in thread
* linux-next: manual merge of the kvm-arm tree with the arm64 tree
@ 2024-03-08  1:54 Stephen Rothwell
  2024-03-08  6:25 ` Oliver Upton
  0 siblings, 1 reply; 83+ messages in thread
From: Stephen Rothwell @ 2024-03-08  1:54 UTC (permalink / raw)
  To: Christoffer Dall, Marc Zyngier, Catalin Marinas, Will Deacon
  Cc: Ard Biesheuvel, Linux Kernel Mailing List,
	Linux Next Mailing List, Mark Brown, Oliver Upton

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

Hi all,

Today's linux-next merge of the kvm-arm tree got a conflict in:

  arch/arm64/kernel/cpufeature.c

between commits:

  203f2b95a882 ("arm64/fpsimd: Support FEAT_FPMR")
  9cce9c6c2c3b ("arm64: mm: Handle LVA support as a CPU feature")
  352b0395b505 ("arm64: Enable 52-bit virtual addressing for 4k and 16k granule configs")
  2aea7b77aabc ("arm64: Use Signed/Unsigned enums for TGRAN{4,16,64} and VARange")

from the arm64 tree and commit:

  da9af5071b25 ("arm64: cpufeature: Detect HCR_EL2.NV1 being RES0")

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 d6679d8b737e,f309fd542c20..000000000000
--- a/arch/arm64/kernel/cpufeature.c
+++ b/arch/arm64/kernel/cpufeature.c
@@@ -754,16 -752,14 +789,17 @@@ static const struct __ftr_reg_entry 
  			       &id_aa64isar1_override),
  	ARM64_FTR_REG_OVERRIDE(SYS_ID_AA64ISAR2_EL1, ftr_id_aa64isar2,
  			       &id_aa64isar2_override),
 +	ARM64_FTR_REG(SYS_ID_AA64ISAR3_EL1, ftr_id_aa64isar3),
  
  	/* Op1 = 0, CRn = 0, CRm = 7 */
 -	ARM64_FTR_REG(SYS_ID_AA64MMFR0_EL1, ftr_id_aa64mmfr0),
 +	ARM64_FTR_REG_OVERRIDE(SYS_ID_AA64MMFR0_EL1, ftr_id_aa64mmfr0,
 +			       &id_aa64mmfr0_override),
  	ARM64_FTR_REG_OVERRIDE(SYS_ID_AA64MMFR1_EL1, ftr_id_aa64mmfr1,
  			       &id_aa64mmfr1_override),
 -	ARM64_FTR_REG(SYS_ID_AA64MMFR2_EL1, ftr_id_aa64mmfr2),
 +	ARM64_FTR_REG_OVERRIDE(SYS_ID_AA64MMFR2_EL1, ftr_id_aa64mmfr2,
 +			       &id_aa64mmfr2_override),
  	ARM64_FTR_REG(SYS_ID_AA64MMFR3_EL1, ftr_id_aa64mmfr3),
+ 	ARM64_FTR_REG(SYS_ID_AA64MMFR4_EL1, ftr_id_aa64mmfr4),
  
  	/* Op1 = 1, CRn = 0, CRm = 0 */
  	ARM64_FTR_REG(SYS_GMID_EL1, ftr_gmid),
@@@ -1088,12 -1084,11 +1125,13 @@@ void __init init_cpu_features(struct cp
  	init_cpu_ftr_reg(SYS_ID_AA64MMFR1_EL1, info->reg_id_aa64mmfr1);
  	init_cpu_ftr_reg(SYS_ID_AA64MMFR2_EL1, info->reg_id_aa64mmfr2);
  	init_cpu_ftr_reg(SYS_ID_AA64MMFR3_EL1, info->reg_id_aa64mmfr3);
+ 	init_cpu_ftr_reg(SYS_ID_AA64MMFR4_EL1, info->reg_id_aa64mmfr4);
  	init_cpu_ftr_reg(SYS_ID_AA64PFR0_EL1, info->reg_id_aa64pfr0);
  	init_cpu_ftr_reg(SYS_ID_AA64PFR1_EL1, info->reg_id_aa64pfr1);
 +	init_cpu_ftr_reg(SYS_ID_AA64PFR2_EL1, info->reg_id_aa64pfr2);
  	init_cpu_ftr_reg(SYS_ID_AA64ZFR0_EL1, info->reg_id_aa64zfr0);
  	init_cpu_ftr_reg(SYS_ID_AA64SMFR0_EL1, info->reg_id_aa64smfr0);
 +	init_cpu_ftr_reg(SYS_ID_AA64FPFR0_EL1, info->reg_id_aa64fpfr0);
  
  	if (id_aa64pfr0_32bit_el0(info->reg_id_aa64pfr0))
  		init_32bit_cpu_features(&info->aarch32);
@@@ -2750,32 -2817,13 +2828,39 @@@ static const struct arm64_cpu_capabilit
  		.type = ARM64_CPUCAP_SYSTEM_FEATURE,
  		.matches = has_lpa2,
  	},
 +	{
 +		.desc = "FPMR",
 +		.type = ARM64_CPUCAP_SYSTEM_FEATURE,
 +		.capability = ARM64_HAS_FPMR,
 +		.matches = has_cpuid_feature,
 +		.cpu_enable = cpu_enable_fpmr,
 +		ARM64_CPUID_FIELDS(ID_AA64PFR2_EL1, FPMR, IMP)
 +	},
 +#ifdef CONFIG_ARM64_VA_BITS_52
 +	{
 +		.capability = ARM64_HAS_VA52,
 +		.type = ARM64_CPUCAP_BOOT_CPU_FEATURE,
 +		.matches = has_cpuid_feature,
 +#ifdef CONFIG_ARM64_64K_PAGES
 +		.desc = "52-bit Virtual Addressing (LVA)",
 +		ARM64_CPUID_FIELDS(ID_AA64MMFR2_EL1, VARange, 52)
 +#else
 +		.desc = "52-bit Virtual Addressing (LPA2)",
 +#ifdef CONFIG_ARM64_4K_PAGES
 +		ARM64_CPUID_FIELDS(ID_AA64MMFR0_EL1, TGRAN4, 52_BIT)
 +#else
 +		ARM64_CPUID_FIELDS(ID_AA64MMFR0_EL1, TGRAN16, 52_BIT)
 +#endif
 +#endif
 +	},
 +#endif
+ 	{
+ 		.desc = "NV1",
+ 		.capability = ARM64_HAS_HCR_NV1,
+ 		.type = ARM64_CPUCAP_SYSTEM_FEATURE,
+ 		.matches = has_nv1,
+ 		ARM64_CPUID_FIELDS_NEG(ID_AA64MMFR4_EL1, E2H0, NI_NV1)
+ 	},
  	{},
  };
  

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

^ permalink raw reply	[flat|nested] 83+ messages in thread
* linux-next: manual merge of the kvm-arm tree with the arm64 tree
@ 2024-03-08  1:47 Stephen Rothwell
  0 siblings, 0 replies; 83+ messages in thread
From: Stephen Rothwell @ 2024-03-08  1:47 UTC (permalink / raw)
  To: Christoffer Dall, Marc Zyngier, Catalin Marinas, Will Deacon
  Cc: Linux Kernel Mailing List, Linux Next Mailing List, Mark Brown,
	Oliver Upton

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

Hi all,

Today's linux-next merge of the kvm-arm tree got a conflict in:

  arch/arm64/include/asm/kvm_arm.h

between commit:

  b6c0b424cb91 ("arm64/fpsimd: Enable host kernel access to FPMR")

from the arm64 tree and commit:

  84de212d739e ("KVM: arm64: Make FEAT_MOPS UNDEF if not advertised to the guest")

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/kvm_arm.h
index 7f45ce9170bb,a1769e415d72..000000000000
--- a/arch/arm64/include/asm/kvm_arm.h
+++ b/arch/arm64/include/asm/kvm_arm.h
@@@ -102,10 -102,8 +102,8 @@@
  #define HCR_HOST_NVHE_PROTECTED_FLAGS (HCR_HOST_NVHE_FLAGS | HCR_TSC)
  #define HCR_HOST_VHE_FLAGS (HCR_RW | HCR_TGE | HCR_E2H)
  
- #define HCRX_GUEST_FLAGS \
- 	(HCRX_EL2_SMPME | HCRX_EL2_TCR2En | \
- 	 (cpus_have_final_cap(ARM64_HAS_MOPS) ? (HCRX_EL2_MSCEn | HCRX_EL2_MCE2) : 0))
+ #define HCRX_GUEST_FLAGS (HCRX_EL2_SMPME | HCRX_EL2_TCR2En)
 -#define HCRX_HOST_FLAGS (HCRX_EL2_MSCEn | HCRX_EL2_TCR2En)
 +#define HCRX_HOST_FLAGS (HCRX_EL2_MSCEn | HCRX_EL2_TCR2En | HCRX_EL2_EnFPM)
  
  /* TCR_EL2 Registers bits */
  #define TCR_EL2_DS		(1UL << 32)

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

^ permalink raw reply	[flat|nested] 83+ messages in thread
* linux-next: manual merge of the kvm-arm tree with the arm64 tree
@ 2024-02-20  2:21 Stephen Rothwell
  0 siblings, 0 replies; 83+ messages in thread
From: Stephen Rothwell @ 2024-02-20  2:21 UTC (permalink / raw)
  To: Christoffer Dall, Marc Zyngier, Catalin Marinas, Will Deacon
  Cc: Ard Biesheuvel, Linux Kernel Mailing List,
	Linux Next Mailing List, Oliver Upton

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

Hi all,

Today's linux-next merge of the kvm-arm tree got a conflict in:

  arch/arm64/kernel/cpufeature.c

between commits:

  352b0395b505 ("arm64: Enable 52-bit virtual addressing for 4k and 16k granule configs")
  2aea7b77aabc ("arm64: Use Signed/Unsigned enums for TGRAN{4,16,64} and VARange")

from the arm64 tree and commit:

  da9af5071b25 ("arm64: cpufeature: Detect HCR_EL2.NV1 being RES0")

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 d380ae783b73,f309fd542c20..000000000000
--- a/arch/arm64/kernel/cpufeature.c
+++ b/arch/arm64/kernel/cpufeature.c
@@@ -721,13 -754,12 +756,14 @@@ static const struct __ftr_reg_entry 
  			       &id_aa64isar2_override),
  
  	/* Op1 = 0, CRn = 0, CRm = 7 */
 -	ARM64_FTR_REG(SYS_ID_AA64MMFR0_EL1, ftr_id_aa64mmfr0),
 +	ARM64_FTR_REG_OVERRIDE(SYS_ID_AA64MMFR0_EL1, ftr_id_aa64mmfr0,
 +			       &id_aa64mmfr0_override),
  	ARM64_FTR_REG_OVERRIDE(SYS_ID_AA64MMFR1_EL1, ftr_id_aa64mmfr1,
  			       &id_aa64mmfr1_override),
 -	ARM64_FTR_REG(SYS_ID_AA64MMFR2_EL1, ftr_id_aa64mmfr2),
 +	ARM64_FTR_REG_OVERRIDE(SYS_ID_AA64MMFR2_EL1, ftr_id_aa64mmfr2,
 +			       &id_aa64mmfr2_override),
  	ARM64_FTR_REG(SYS_ID_AA64MMFR3_EL1, ftr_id_aa64mmfr3),
+ 	ARM64_FTR_REG(SYS_ID_AA64MMFR4_EL1, ftr_id_aa64mmfr4),
  
  	/* Op1 = 1, CRn = 0, CRm = 0 */
  	ARM64_FTR_REG(SYS_GMID_EL1, ftr_gmid),
@@@ -2701,24 -2817,13 +2779,31 @@@ static const struct arm64_cpu_capabilit
  		.type = ARM64_CPUCAP_SYSTEM_FEATURE,
  		.matches = has_lpa2,
  	},
 +#ifdef CONFIG_ARM64_VA_BITS_52
 +	{
 +		.capability = ARM64_HAS_VA52,
 +		.type = ARM64_CPUCAP_BOOT_CPU_FEATURE,
 +		.matches = has_cpuid_feature,
 +#ifdef CONFIG_ARM64_64K_PAGES
 +		.desc = "52-bit Virtual Addressing (LVA)",
 +		ARM64_CPUID_FIELDS(ID_AA64MMFR2_EL1, VARange, 52)
 +#else
 +		.desc = "52-bit Virtual Addressing (LPA2)",
 +#ifdef CONFIG_ARM64_4K_PAGES
 +		ARM64_CPUID_FIELDS(ID_AA64MMFR0_EL1, TGRAN4, 52_BIT)
 +#else
 +		ARM64_CPUID_FIELDS(ID_AA64MMFR0_EL1, TGRAN16, 52_BIT)
 +#endif
 +#endif
 +	},
 +#endif
+ 	{
+ 		.desc = "NV1",
+ 		.capability = ARM64_HAS_HCR_NV1,
+ 		.type = ARM64_CPUCAP_SYSTEM_FEATURE,
+ 		.matches = has_nv1,
+ 		ARM64_CPUID_FIELDS_NEG(ID_AA64MMFR4_EL1, E2H0, NI_NV1)
+ 	},
  	{},
  };
  

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

^ permalink raw reply	[flat|nested] 83+ messages in thread
* linux-next: manual merge of the kvm-arm tree with the arm64 tree
@ 2024-02-19  2:58 Stephen Rothwell
  2024-02-19 12:14 ` Catalin Marinas
  0 siblings, 1 reply; 83+ messages in thread
From: Stephen Rothwell @ 2024-02-19  2:58 UTC (permalink / raw)
  To: Christoffer Dall, Marc Zyngier, Catalin Marinas, Will Deacon
  Cc: Ard Biesheuvel, Linux Kernel Mailing List,
	Linux Next Mailing List, Oliver Upton

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

Hi all,

Today's linux-next merge of the kvm-arm tree got a conflict in:

  arch/arm64/kernel/cpufeature.c

between commits:

  9cce9c6c2c3b ("arm64: mm: Handle LVA support as a CPU feature")
  352b0395b505 ("arm64: Enable 52-bit virtual addressing for 4k and 16k granule configs")

from the arm64 tree and commit:

  da9af5071b25 ("arm64: cpufeature: Detect HCR_EL2.NV1 being RES0")

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 0be9296e9253,f309fd542c20..000000000000
--- a/arch/arm64/kernel/cpufeature.c
+++ b/arch/arm64/kernel/cpufeature.c
@@@ -721,13 -754,12 +756,14 @@@ static const struct __ftr_reg_entry 
  			       &id_aa64isar2_override),
  
  	/* Op1 = 0, CRn = 0, CRm = 7 */
 -	ARM64_FTR_REG(SYS_ID_AA64MMFR0_EL1, ftr_id_aa64mmfr0),
 +	ARM64_FTR_REG_OVERRIDE(SYS_ID_AA64MMFR0_EL1, ftr_id_aa64mmfr0,
 +			       &id_aa64mmfr0_override),
  	ARM64_FTR_REG_OVERRIDE(SYS_ID_AA64MMFR1_EL1, ftr_id_aa64mmfr1,
  			       &id_aa64mmfr1_override),
 -	ARM64_FTR_REG(SYS_ID_AA64MMFR2_EL1, ftr_id_aa64mmfr2),
 +	ARM64_FTR_REG_OVERRIDE(SYS_ID_AA64MMFR2_EL1, ftr_id_aa64mmfr2,
 +			       &id_aa64mmfr2_override),
  	ARM64_FTR_REG(SYS_ID_AA64MMFR3_EL1, ftr_id_aa64mmfr3),
+ 	ARM64_FTR_REG(SYS_ID_AA64MMFR4_EL1, ftr_id_aa64mmfr4),
  
  	/* Op1 = 1, CRn = 0, CRm = 0 */
  	ARM64_FTR_REG(SYS_GMID_EL1, ftr_gmid),
@@@ -2701,33 -2817,13 +2779,40 @@@ static const struct arm64_cpu_capabilit
  		.type = ARM64_CPUCAP_SYSTEM_FEATURE,
  		.matches = has_lpa2,
  	},
 +#ifdef CONFIG_ARM64_VA_BITS_52
 +	{
 +		.capability = ARM64_HAS_VA52,
 +		.type = ARM64_CPUCAP_BOOT_CPU_FEATURE,
 +		.matches = has_cpuid_feature,
 +		.field_width = 4,
 +#ifdef CONFIG_ARM64_64K_PAGES
 +		.desc = "52-bit Virtual Addressing (LVA)",
 +		.sign = FTR_SIGNED,
 +		.sys_reg = SYS_ID_AA64MMFR2_EL1,
 +		.field_pos = ID_AA64MMFR2_EL1_VARange_SHIFT,
 +		.min_field_value = ID_AA64MMFR2_EL1_VARange_52,
 +#else
 +		.desc = "52-bit Virtual Addressing (LPA2)",
 +		.sys_reg = SYS_ID_AA64MMFR0_EL1,
 +#ifdef CONFIG_ARM64_4K_PAGES
 +		.sign = FTR_SIGNED,
 +		.field_pos = ID_AA64MMFR0_EL1_TGRAN4_SHIFT,
 +		.min_field_value = ID_AA64MMFR0_EL1_TGRAN4_52_BIT,
 +#else
 +		.sign = FTR_UNSIGNED,
 +		.field_pos = ID_AA64MMFR0_EL1_TGRAN16_SHIFT,
 +		.min_field_value = ID_AA64MMFR0_EL1_TGRAN16_52_BIT,
 +#endif
 +#endif
 +	},
 +#endif
+ 	{
+ 		.desc = "NV1",
+ 		.capability = ARM64_HAS_HCR_NV1,
+ 		.type = ARM64_CPUCAP_SYSTEM_FEATURE,
+ 		.matches = has_nv1,
+ 		ARM64_CPUID_FIELDS_NEG(ID_AA64MMFR4_EL1, E2H0, NI_NV1)
+ 	},
  	{},
  };
  

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

^ permalink raw reply	[flat|nested] 83+ messages in thread
* linux-next: manual merge of the kvm-arm tree with the arm64 tree
@ 2023-10-24  2:28 Stephen Rothwell
  2023-10-24  6:49 ` Oliver Upton
  0 siblings, 1 reply; 83+ messages in thread
From: Stephen Rothwell @ 2023-10-24  2:28 UTC (permalink / raw)
  To: Christoffer Dall, Marc Zyngier, Catalin Marinas, Will Deacon
  Cc: Ard Biesheuvel, Linux Kernel Mailing List,
	Linux Next Mailing List, Oliver Upton, Vincent Donnefort

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

Hi all,

Today's linux-next merge of the kvm-arm tree got a conflict in:

  arch/arm64/kvm/mmu.c

between commits:

  0e0fb2f69c1b ("arm64: kvm: avoid CONFIG_PGTABLE_LEVELS for runtime levels")
  8d35f7bcee55 ("arm64: kvm: Limit HYP VA and host S2 range to 48 bits when LPA2 is in effect")

from the arm64 tree and commit:

  bf92834e6f6e ("KVM: arm64: Use folio for THP adjustment")

from the kvm-arm tree.

I fixed it up (the latter removed the struct updated by the former, so
I just did that) 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

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

^ permalink raw reply	[flat|nested] 83+ messages in thread
* linux-next: manual merge of the kvm-arm tree with the arm64 tree
@ 2023-10-17  1:30 Stephen Rothwell
  2023-10-17 11:13 ` Catalin Marinas
  2023-11-01  2:36 ` Stephen Rothwell
  0 siblings, 2 replies; 83+ messages in thread
From: Stephen Rothwell @ 2023-10-17  1:30 UTC (permalink / raw)
  To: Christoffer Dall, Marc Zyngier, Catalin Marinas, Will Deacon
  Cc: Linux Kernel Mailing List, Linux Next Mailing List, Mark Rutland,
	Oliver Upton

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

Hi all,

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.

-- 
Cheers,
Stephen Rothwell

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

^ permalink raw reply	[flat|nested] 83+ messages in thread
* linux-next: manual merge of the kvm-arm tree with the arm64 tree
@ 2023-06-15  2:45 Stephen Rothwell
  2023-06-15  7:37 ` Oliver Upton
  0 siblings, 1 reply; 83+ messages in thread
From: Stephen Rothwell @ 2023-06-15  2:45 UTC (permalink / raw)
  To: Christoffer Dall, Marc Zyngier, Catalin Marinas, Will Deacon
  Cc: Linux Kernel Mailing List, Linux Next Mailing List, Mark Rutland,
	Oliver Upton

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

Hi all,

Today's linux-next merge of the kvm-arm tree got a conflict in:

  arch/arm64/kernel/kaslr.c

between commit:

  6e13b6b923b3 ("arm64: kaslr: split kaslr/module initialization")
  e46b7103aef3 ("arm64: module: move module randomization to module.c")

from the arm64 tree and commit:

  0ddc312b7c73 ("arm64: Turn kaslr_feature_override into a generic SW feature override")

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/kaslr.c
index 17f96a19781d,5d4ce7f5f157..000000000000
--- a/arch/arm64/kernel/kaslr.c
+++ b/arch/arm64/kernel/kaslr.c
@@@ -4,33 -4,46 +4,33 @@@
   */
  
  #include <linux/cache.h>
 -#include <linux/crc32.h>
  #include <linux/init.h>
 -#include <linux/libfdt.h>
 -#include <linux/mm_types.h>
 -#include <linux/sched.h>
 -#include <linux/types.h>
 -#include <linux/pgtable.h>
 -#include <linux/random.h>
 +#include <linux/printk.h>
  
 -#include <asm/fixmap.h>
 -#include <asm/kernel-pgtable.h>
 +#include <asm/cpufeature.h>
  #include <asm/memory.h>
 -#include <asm/mmu.h>
 -#include <asm/sections.h>
 -#include <asm/setup.h>
  
 -u64 __ro_after_init module_alloc_base;
  u16 __initdata memstart_offset_seed;
  
- struct arm64_ftr_override kaslr_feature_override __initdata;
- 
 -static int __init kaslr_init(void)
 +bool __ro_after_init __kaslr_is_enabled = false;
 +
 +void __init kaslr_init(void)
  {
- 	if (kaslr_feature_override.val & kaslr_feature_override.mask & 0xf) {
 -	u64 module_range;
 -	u32 seed;
 -
 -	/*
 -	 * Set a reasonable default for module_alloc_base in case
 -	 * we end up running with module randomization disabled.
 -	 */
 -	module_alloc_base = (u64)_etext - MODULES_VSIZE;
 -
+ 	if (cpuid_feature_extract_unsigned_field(arm64_sw_feature_override.val &
+ 						 arm64_sw_feature_override.mask,
+ 						 ARM64_SW_FEATURE_OVERRIDE_NOKASLR)) {
  		pr_info("KASLR disabled on command line\n");
 -		return 0;
 +		return;
  	}
  
 -	if (!kaslr_enabled()) {
 +	/*
 +	 * The KASLR offset modulo MIN_KIMG_ALIGN is taken from the physical
 +	 * placement of the image rather than from the seed, so a displacement
 +	 * of less than MIN_KIMG_ALIGN means that no seed was provided.
 +	 */
 +	if (kaslr_offset() < MIN_KIMG_ALIGN) {
  		pr_warn("KASLR disabled due to lack of seed\n");
 -		return 0;
 +		return;
  	}
  
  	pr_info("KASLR enabled\n");

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

^ permalink raw reply	[flat|nested] 83+ messages in thread
* linux-next: manual merge of the kvm-arm tree with the arm64 tree
@ 2023-06-15  2:22 Stephen Rothwell
  2023-06-15  7:14 ` Catalin Marinas
  2023-07-03  0:50 ` Stephen Rothwell
  0 siblings, 2 replies; 83+ messages in thread
From: Stephen Rothwell @ 2023-06-15  2:22 UTC (permalink / raw)
  To: Christoffer Dall, Marc Zyngier, Catalin Marinas, Will Deacon
  Cc: Joey Gouly, Kristina Martsenko, Linux Kernel Mailing List,
	Linux Next Mailing List, Oliver Upton

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

Hi all,

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.

-- 
Cheers,
Stephen Rothwell

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,
+ 	},
  	{},
  };
  

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

^ permalink raw reply	[flat|nested] 83+ messages in thread
* linux-next: manual merge of the kvm-arm tree with the arm64 tree
@ 2023-06-06  1:49 Stephen Rothwell
  2023-06-06  9:20 ` Catalin Marinas
  2023-06-07  1:05 ` Stephen Rothwell
  0 siblings, 2 replies; 83+ messages in thread
From: Stephen Rothwell @ 2023-06-06  1:49 UTC (permalink / raw)
  To: Christoffer Dall, Marc Zyngier, Catalin Marinas, Will Deacon
  Cc: Joey Gouly, Kristina Martsenko, Linux Kernel Mailing List,
	Linux Next Mailing List, Oliver Upton

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

Hi all,

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")
  c1fa32c8f189 ("arm64: cpufeature: add TCR2 cpucap")
  b5a8e35236ee ("arm64: cpufeature: add Permission Indirection Extension cpucap")

from the arm64 tree and commit:

  c876c3f182a5 ("KVM: arm64: Relax trapping of CTR_EL0 when FEAT_EVT is available")

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 a74f41c7280f,4a2ab3f366de..000000000000
--- a/arch/arm64/kernel/cpufeature.c
+++ b/arch/arm64/kernel/cpufeature.c
@@@ -2662,35 -2641,17 +2662,46 @@@ 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,
 +		.sys_reg = SYS_ID_AA64MMFR3_EL1,
 +		.sign = FTR_UNSIGNED,
 +		.field_pos = ID_AA64MMFR3_EL1_TCRX_SHIFT,
 +		.field_width = 4,
 +		.min_field_value = ID_AA64MMFR3_EL1_TCRX_IMP,
 +		.matches = has_cpuid_feature,
 +	},
 +	{
 +		.desc = "Stage-1 Permission Indirection Extension (S1PIE)",
 +		.capability = ARM64_HAS_S1PIE,
 +		.type = ARM64_CPUCAP_BOOT_CPU_FEATURE,
 +		.sys_reg = SYS_ID_AA64MMFR3_EL1,
 +		.sign = FTR_UNSIGNED,
 +		.field_pos = ID_AA64MMFR3_EL1_S1PIE_SHIFT,
 +		.field_width = 4,
 +		.min_field_value = ID_AA64MMFR3_EL1_S1PIE_IMP,
 +		.matches = has_cpuid_feature,
 +	},
+ 	{
+ 		.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,
+ 	},
  	{},
  };
  

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

^ permalink raw reply	[flat|nested] 83+ messages in thread
* linux-next: manual merge of the kvm-arm tree with the arm64 tree
@ 2023-02-06  1:44 Stephen Rothwell
  2023-02-06  4:21 ` Stephen Rothwell
  2023-02-06  8:37 ` Marc Zyngier
  0 siblings, 2 replies; 83+ messages in thread
From: Stephen Rothwell @ 2023-02-06  1:44 UTC (permalink / raw)
  To: Christoffer Dall, Marc Zyngier, Catalin Marinas, Will Deacon
  Cc: Linux Kernel Mailing List, Linux Next Mailing List, Mark Brown,
	Oliver Upton, Quentin Perret

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

Hi all,

Today's linux-next merge of the kvm-arm tree got a conflict in:

  arch/arm64/kernel/hyp-stub.S

between commit:

  f122576f3533 ("arm64/sme: Enable host kernel to access ZT0")

from the arm64 tree and commit:

  e2d4f5ae1771 ("KVM: arm64: Introduce finalise_el2_state macro")

from the kvm-arm tree.

I fixed it up (the code modified by the former was moved by the latter,
so I applied the following merge fix patch) 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.

I hope I got this right :-)

From: Stephen Rothwell <sfr@canb.auug.org.au>
Date: Mon, 6 Feb 2023 12:40:16 +1100
Subject: [PATCH] fix up for "KVM: arm64: Introduce finalise_el2_state macro"

interacting with "arm64/sme: Enable host kernel to access ZT0"

Signed-off-by: Stephen Rothwell <sfr@canb.auug.org.au>
---
 arch/arm64/include/asm/el2_setup.h | 6 ++++++
 1 file changed, 6 insertions(+)

diff --git a/arch/arm64/include/asm/el2_setup.h b/arch/arm64/include/asm/el2_setup.h
index 0bd6ed77e4a5..5f821e5c52a9 100644
--- a/arch/arm64/include/asm/el2_setup.h
+++ b/arch/arm64/include/asm/el2_setup.h
@@ -269,6 +269,12 @@
 	orr	x0, x0, SMCR_ELx_FA64_MASK
 .Lskip_sme_fa64_\@:
 
+	// ZT0 available?
+	__check_override id_aa64smfr0 ID_AA64SMFR0_EL1_SMEver_SHIFT 4 .Linit_sme_zt0_\@ .Lskip_sme_zt0_\@
+.Linit_sme_zt0_\@:
+	orr	x0, x0, SMCR_ELx_EZT0_MASK
+.Lskip_sme_zt0_\@:
+
 	orr	x0, x0, #SMCR_ELx_LEN_MASK	// Enable full SME vector
 	msr_s	SYS_SMCR_EL2, x0		// length for EL1.
 
-- 
2.35.1

-- 
Cheers,
Stephen Rothwell

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

^ permalink raw reply related	[flat|nested] 83+ messages in thread
* linux-next: manual merge of the kvm-arm tree with the arm64 tree
@ 2022-09-19  4:05 Stephen Rothwell
  2022-09-19  9:04 ` Marc Zyngier
  0 siblings, 1 reply; 83+ messages in thread
From: Stephen Rothwell @ 2022-09-19  4:05 UTC (permalink / raw)
  To: Christoffer Dall, Marc Zyngier, Catalin Marinas, Will Deacon
  Cc: Linux Kernel Mailing List, Linux Next Mailing List, Mark Brown,
	Oliver Upton

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

Hi all,

Today's linux-next merge of the kvm-arm tree got a conflict in:

  arch/arm64/kvm/sys_regs.c

between commit:

  55adc08d7e64 ("arm64/sysreg: Add _EL1 into ID_AA64PFR0_EL1 definition names")

from the arm64 tree and commit:

  cdd5036d048c ("KVM: arm64: Drop raz parameter from read_id_reg()")

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/kvm/sys_regs.c
index 2ef1121ab844,9569772cf09a..000000000000
--- a/arch/arm64/kvm/sys_regs.c
+++ b/arch/arm64/kvm/sys_regs.c
@@@ -1208,9 -1210,9 +1210,9 @@@ static int set_id_aa64pfr0_el1(struct k
  		return -EINVAL;
  
  	/* We can only differ with CSV[23], and anything else is an error */
- 	val ^= read_id_reg(vcpu, rd, false);
+ 	val ^= read_id_reg(vcpu, rd);
 -	val &= ~((0xFUL << ID_AA64PFR0_CSV2_SHIFT) |
 -		 (0xFUL << ID_AA64PFR0_CSV3_SHIFT));
 +	val &= ~((0xFUL << ID_AA64PFR0_EL1_CSV2_SHIFT) |
 +		 (0xFUL << ID_AA64PFR0_EL1_CSV3_SHIFT));
  	if (val)
  		return -EINVAL;
  

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

^ permalink raw reply	[flat|nested] 83+ messages in thread
* linux-next: manual merge of the kvm-arm tree with the arm64 tree
@ 2022-05-04  4:35 Stephen Rothwell
  2022-05-04  7:06 ` Marc Zyngier
  2022-05-23  6:36 ` Stephen Rothwell
  0 siblings, 2 replies; 83+ messages in thread
From: Stephen Rothwell @ 2022-05-04  4:35 UTC (permalink / raw)
  To: Christoffer Dall, Marc Zyngier, Catalin Marinas, Will Deacon
  Cc: Alexandru Elisei, Linux Kernel Mailing List,
	Linux Next Mailing List, Oliver Upton

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

Hi all,

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.

-- 
Cheers,
Stephen Rothwell

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

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

^ permalink raw reply	[flat|nested] 83+ messages in thread
* linux-next: manual merge of the kvm-arm tree with the arm64 tree
@ 2021-08-19  4:05 Stephen Rothwell
  2021-08-20  9:27 ` Catalin Marinas
  0 siblings, 1 reply; 83+ messages in thread
From: Stephen Rothwell @ 2021-08-19  4:05 UTC (permalink / raw)
  To: Christoffer Dall, Marc Zyngier, Catalin Marinas, Will Deacon
  Cc: Anshuman Khandual, Linux Kernel Mailing List, Linux Next Mailing List

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

Hi all,

Today's linux-next merge of the kvm-arm tree got a conflict in:

  arch/arm64/include/asm/sysreg.h

between commit:

  79d82cbcbb3d ("arm64/kexec: Test page size support with new TGRAN range values")

from the arm64 tree and commit:

  504c6295b998 ("arm64/mm: Add remaining ID_AA64MMFR0_PARANGE_ macros")

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/sysreg.h
index f2e06e7c0a31,1972e4b9be5c..000000000000
--- a/arch/arm64/include/asm/sysreg.h
+++ b/arch/arm64/include/asm/sysreg.h
@@@ -847,16 -847,17 +847,21 @@@
  #define ID_AA64MMFR0_ASID_SHIFT		4
  #define ID_AA64MMFR0_PARANGE_SHIFT	0
  
 -#define ID_AA64MMFR0_TGRAN4_NI		0xf
 -#define ID_AA64MMFR0_TGRAN4_SUPPORTED	0x0
 -#define ID_AA64MMFR0_TGRAN64_NI		0xf
 -#define ID_AA64MMFR0_TGRAN64_SUPPORTED	0x0
 -#define ID_AA64MMFR0_TGRAN16_NI		0x0
 -#define ID_AA64MMFR0_TGRAN16_SUPPORTED	0x1
 +#define ID_AA64MMFR0_TGRAN4_NI			0xf
 +#define ID_AA64MMFR0_TGRAN4_SUPPORTED_MIN	0x0
 +#define ID_AA64MMFR0_TGRAN4_SUPPORTED_MAX	0x7
 +#define ID_AA64MMFR0_TGRAN64_NI			0xf
 +#define ID_AA64MMFR0_TGRAN64_SUPPORTED_MIN	0x0
 +#define ID_AA64MMFR0_TGRAN64_SUPPORTED_MAX	0x7
 +#define ID_AA64MMFR0_TGRAN16_NI			0x0
 +#define ID_AA64MMFR0_TGRAN16_SUPPORTED_MIN	0x1
 +#define ID_AA64MMFR0_TGRAN16_SUPPORTED_MAX	0xf
 +
+ #define ID_AA64MMFR0_PARANGE_32		0x0
+ #define ID_AA64MMFR0_PARANGE_36		0x1
+ #define ID_AA64MMFR0_PARANGE_40		0x2
+ #define ID_AA64MMFR0_PARANGE_42		0x3
+ #define ID_AA64MMFR0_PARANGE_44		0x4
  #define ID_AA64MMFR0_PARANGE_48		0x5
  #define ID_AA64MMFR0_PARANGE_52		0x6
  
@@@ -1032,16 -1035,19 +1039,19 @@@
  
  #if defined(CONFIG_ARM64_4K_PAGES)
  #define ID_AA64MMFR0_TGRAN_SHIFT		ID_AA64MMFR0_TGRAN4_SHIFT
+ #define ID_AA64MMFR0_TGRAN_2_SHIFT		ID_AA64MMFR0_TGRAN4_2_SHIFT
 -#define ID_AA64MMFR0_TGRAN_SUPPORTED_MIN	ID_AA64MMFR0_TGRAN4_SUPPORTED
 -#define ID_AA64MMFR0_TGRAN_SUPPORTED_MAX	0x7
 +#define ID_AA64MMFR0_TGRAN_SUPPORTED_MIN	ID_AA64MMFR0_TGRAN4_SUPPORTED_MIN
 +#define ID_AA64MMFR0_TGRAN_SUPPORTED_MAX	ID_AA64MMFR0_TGRAN4_SUPPORTED_MAX
  #elif defined(CONFIG_ARM64_16K_PAGES)
  #define ID_AA64MMFR0_TGRAN_SHIFT		ID_AA64MMFR0_TGRAN16_SHIFT
+ #define ID_AA64MMFR0_TGRAN_2_SHIFT		ID_AA64MMFR0_TGRAN16_2_SHIFT
 -#define ID_AA64MMFR0_TGRAN_SUPPORTED_MIN	ID_AA64MMFR0_TGRAN16_SUPPORTED
 -#define ID_AA64MMFR0_TGRAN_SUPPORTED_MAX	0xF
 +#define ID_AA64MMFR0_TGRAN_SUPPORTED_MIN	ID_AA64MMFR0_TGRAN16_SUPPORTED_MIN
 +#define ID_AA64MMFR0_TGRAN_SUPPORTED_MAX	ID_AA64MMFR0_TGRAN16_SUPPORTED_MAX
  #elif defined(CONFIG_ARM64_64K_PAGES)
  #define ID_AA64MMFR0_TGRAN_SHIFT		ID_AA64MMFR0_TGRAN64_SHIFT
+ #define ID_AA64MMFR0_TGRAN_2_SHIFT		ID_AA64MMFR0_TGRAN64_2_SHIFT
 -#define ID_AA64MMFR0_TGRAN_SUPPORTED_MIN	ID_AA64MMFR0_TGRAN64_SUPPORTED
 -#define ID_AA64MMFR0_TGRAN_SUPPORTED_MAX	0x7
 +#define ID_AA64MMFR0_TGRAN_SUPPORTED_MIN	ID_AA64MMFR0_TGRAN64_SUPPORTED_MIN
 +#define ID_AA64MMFR0_TGRAN_SUPPORTED_MAX	ID_AA64MMFR0_TGRAN64_SUPPORTED_MAX
  #endif
  
  #define MVFR2_FPMISC_SHIFT		4

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

^ permalink raw reply	[flat|nested] 83+ messages in thread
* linux-next: manual merge of the kvm-arm tree with the arm64 tree
@ 2021-08-12  3:33 Stephen Rothwell
  0 siblings, 0 replies; 83+ messages in thread
From: Stephen Rothwell @ 2021-08-12  3:33 UTC (permalink / raw)
  To: Christoffer Dall, Marc Zyngier, Catalin Marinas, Will Deacon
  Cc: Anshuman Khandual, Linux Kernel Mailing List, Linux Next Mailing List

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

Hi all,

Today's linux-next merge of the kvm-arm tree got a conflict in:

  arch/arm64/include/asm/sysreg.h

between commit:

  79d82cbcbb3d ("arm64/kexec: Test page size support with new TGRAN range values")

from the arm64 tree and commit:

  b31578f62717 ("arm64/mm: Define ID_AA64MMFR0_TGRAN_2_SHIFT")

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/sysreg.h
index f2e06e7c0a31,943d31d92b5b..000000000000
--- a/arch/arm64/include/asm/sysreg.h
+++ b/arch/arm64/include/asm/sysreg.h
@@@ -1032,16 -1028,19 +1032,19 @@@
  
  #if defined(CONFIG_ARM64_4K_PAGES)
  #define ID_AA64MMFR0_TGRAN_SHIFT		ID_AA64MMFR0_TGRAN4_SHIFT
+ #define ID_AA64MMFR0_TGRAN_2_SHIFT		ID_AA64MMFR0_TGRAN4_2_SHIFT
 -#define ID_AA64MMFR0_TGRAN_SUPPORTED_MIN	ID_AA64MMFR0_TGRAN4_SUPPORTED
 -#define ID_AA64MMFR0_TGRAN_SUPPORTED_MAX	0x7
 +#define ID_AA64MMFR0_TGRAN_SUPPORTED_MIN	ID_AA64MMFR0_TGRAN4_SUPPORTED_MIN
 +#define ID_AA64MMFR0_TGRAN_SUPPORTED_MAX	ID_AA64MMFR0_TGRAN4_SUPPORTED_MAX
  #elif defined(CONFIG_ARM64_16K_PAGES)
  #define ID_AA64MMFR0_TGRAN_SHIFT		ID_AA64MMFR0_TGRAN16_SHIFT
+ #define ID_AA64MMFR0_TGRAN_2_SHIFT		ID_AA64MMFR0_TGRAN16_2_SHIFT
 -#define ID_AA64MMFR0_TGRAN_SUPPORTED_MIN	ID_AA64MMFR0_TGRAN16_SUPPORTED
 -#define ID_AA64MMFR0_TGRAN_SUPPORTED_MAX	0xF
 +#define ID_AA64MMFR0_TGRAN_SUPPORTED_MIN	ID_AA64MMFR0_TGRAN16_SUPPORTED_MIN
 +#define ID_AA64MMFR0_TGRAN_SUPPORTED_MAX	ID_AA64MMFR0_TGRAN16_SUPPORTED_MAX
  #elif defined(CONFIG_ARM64_64K_PAGES)
  #define ID_AA64MMFR0_TGRAN_SHIFT		ID_AA64MMFR0_TGRAN64_SHIFT
+ #define ID_AA64MMFR0_TGRAN_2_SHIFT		ID_AA64MMFR0_TGRAN64_2_SHIFT
 -#define ID_AA64MMFR0_TGRAN_SUPPORTED_MIN	ID_AA64MMFR0_TGRAN64_SUPPORTED
 -#define ID_AA64MMFR0_TGRAN_SUPPORTED_MAX	0x7
 +#define ID_AA64MMFR0_TGRAN_SUPPORTED_MIN	ID_AA64MMFR0_TGRAN64_SUPPORTED_MIN
 +#define ID_AA64MMFR0_TGRAN_SUPPORTED_MAX	ID_AA64MMFR0_TGRAN64_SUPPORTED_MAX
  #endif
  
  #define MVFR2_FPMISC_SHIFT		4

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

^ permalink raw reply	[flat|nested] 83+ messages in thread
* linux-next: manual merge of the kvm-arm tree with the arm64 tree
@ 2021-06-23  5:58 Stephen Rothwell
  0 siblings, 0 replies; 83+ messages in thread
From: Stephen Rothwell @ 2021-06-23  5:58 UTC (permalink / raw)
  To: Christoffer Dall, Marc Zyngier, Catalin Marinas, Will Deacon
  Cc: Linux Kernel Mailing List, Linux Next Mailing List,
	Peter Collingbourne, Steven Price

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

Hi all,

Today's linux-next merge of the kvm-arm tree got a conflict in:

  arch/arm64/include/asm/mte.h

between commit:

  013bb59dbb7c ("arm64: mte: handle tags zeroing at page allocation time")

from the arm64 tree and commit:

  69e3b846d8a7 ("arm64: mte: Sync tags for pages where PTE is untagged")

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/mte.h
index 67bf259ae768,347ef38a35f7..000000000000
--- a/arch/arm64/include/asm/mte.h
+++ b/arch/arm64/include/asm/mte.h
@@@ -37,8 -37,7 +37,8 @@@ void mte_free_tag_storage(char *storage
  /* track which pages have valid allocation tags */
  #define PG_mte_tagged	PG_arch_2
  
 +void mte_zero_clear_page_tags(void *addr);
- void mte_sync_tags(pte_t *ptep, pte_t pte);
+ void mte_sync_tags(pte_t old_pte, pte_t pte);
  void mte_copy_page_tags(void *kto, const void *kfrom);
  void mte_thread_init_user(void);
  void mte_thread_switch(struct task_struct *next);
@@@ -54,10 -53,7 +54,10 @@@ int mte_ptrace_copy_tags(struct task_st
  /* unused if !CONFIG_ARM64_MTE, silence the compiler */
  #define PG_mte_tagged	0
  
 +static inline void mte_zero_clear_page_tags(void *addr)
 +{
 +}
- static inline void mte_sync_tags(pte_t *ptep, pte_t pte)
+ static inline void mte_sync_tags(pte_t old_pte, pte_t pte)
  {
  }
  static inline void mte_copy_page_tags(void *kto, const void *kfrom)

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

^ permalink raw reply	[flat|nested] 83+ messages in thread
* linux-next: manual merge of the kvm-arm tree with the arm64 tree
@ 2021-04-13  5:43 Stephen Rothwell
  2021-04-13 11:21 ` Ard Biesheuvel
  0 siblings, 1 reply; 83+ messages in thread
From: Stephen Rothwell @ 2021-04-13  5:43 UTC (permalink / raw)
  To: Christoffer Dall, Marc Zyngier, Catalin Marinas, Will Deacon
  Cc: Ard Biesheuvel, Linux Kernel Mailing List,
	Linux Next Mailing List, Quentin Perret

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

Hi all,

Today's linux-next merge of the kvm-arm tree got a conflict in:

  arch/arm64/include/asm/assembler.h

between commits:

  27248fe1abb2 ("arm64: assembler: remove conditional NEON yield macros")
  13150149aa6d ("arm64: fpsimd: run kernel mode NEON with softirqs disabled")

from the arm64 tree and commits:

  8f4de66e247b ("arm64: asm: Provide set_sctlr_el2 macro")
  755db23420a1 ("KVM: arm64: Generate final CTR_EL0 value when running in Protected mode")

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/assembler.h
index ab569b0b45fc,34ddd8a0f3dd..000000000000
--- a/arch/arm64/include/asm/assembler.h
+++ b/arch/arm64/include/asm/assembler.h
@@@ -15,7 -15,7 +15,8 @@@
  #include <asm-generic/export.h>
  
  #include <asm/asm-offsets.h>
 +#include <asm/alternative.h>
+ #include <asm/asm-bug.h>
  #include <asm/cpufeature.h>
  #include <asm/cputype.h>
  #include <asm/debug-monitors.h>
@@@ -701,25 -705,95 +714,33 @@@ USER(\label, ic	ivau, \tmp2)			// inval
  	isb
  .endm
  
+ .macro set_sctlr_el1, reg
+ 	set_sctlr sctlr_el1, \reg
+ .endm
+ 
+ .macro set_sctlr_el2, reg
+ 	set_sctlr sctlr_el2, \reg
+ .endm
+ 
 -/*
 - * Check whether to yield to another runnable task from kernel mode NEON code
 - * (which runs with preemption disabled).
 - *
 - * if_will_cond_yield_neon
 - *        // pre-yield patchup code
 - * do_cond_yield_neon
 - *        // post-yield patchup code
 - * endif_yield_neon    <label>
 - *
 - * where <label> is optional, and marks the point where execution will resume
 - * after a yield has been performed. If omitted, execution resumes right after
 - * the endif_yield_neon invocation. Note that the entire sequence, including
 - * the provided patchup code, will be omitted from the image if
 - * CONFIG_PREEMPTION is not defined.
 - *
 - * As a convenience, in the case where no patchup code is required, the above
 - * sequence may be abbreviated to
 - *
 - * cond_yield_neon <label>
 - *
 - * Note that the patchup code does not support assembler directives that change
 - * the output section, any use of such directives is undefined.
 - *
 - * The yield itself consists of the following:
 - * - Check whether the preempt count is exactly 1 and a reschedule is also
 - *   needed. If so, calling of preempt_enable() in kernel_neon_end() will
 - *   trigger a reschedule. If it is not the case, yielding is pointless.
 - * - Disable and re-enable kernel mode NEON, and branch to the yield fixup
 - *   code.
 - *
 - * This macro sequence may clobber all CPU state that is not guaranteed by the
 - * AAPCS to be preserved across an ordinary function call.
 - */
 -
 -	.macro		cond_yield_neon, lbl
 -	if_will_cond_yield_neon
 -	do_cond_yield_neon
 -	endif_yield_neon	\lbl
 -	.endm
 -
 -	.macro		if_will_cond_yield_neon
 -#ifdef CONFIG_PREEMPTION
 -	get_current_task	x0
 -	ldr		x0, [x0, #TSK_TI_PREEMPT]
 -	sub		x0, x0, #PREEMPT_DISABLE_OFFSET
 -	cbz		x0, .Lyield_\@
 -	/* fall through to endif_yield_neon */
 -	.subsection	1
 -.Lyield_\@ :
 -#else
 -	.section	".discard.cond_yield_neon", "ax"
 -#endif
 -	.endm
 -
 -	.macro		do_cond_yield_neon
 -	bl		kernel_neon_end
 -	bl		kernel_neon_begin
 -	.endm
 -
 -	.macro		endif_yield_neon, lbl
 -	.ifnb		\lbl
 -	b		\lbl
 -	.else
 -	b		.Lyield_out_\@
 -	.endif
 -	.previous
 -.Lyield_out_\@ :
 -	.endm
 -
  	/*
 -	 * Check whether preempt-disabled code should yield as soon as it
 -	 * is able. This is the case if re-enabling preemption a single
 -	 * time results in a preempt count of zero, and the TIF_NEED_RESCHED
 -	 * flag is set. (Note that the latter is stored negated in the
 -	 * top word of the thread_info::preempt_count field)
 +	 * Check whether preempt/bh-disabled asm code should yield as soon as
 +	 * it is able. This is the case if we are currently running in task
 +	 * context, and either a softirq is pending, or the TIF_NEED_RESCHED
 +	 * flag is set and re-enabling preemption a single time would result in
 +	 * a preempt count of zero. (Note that the TIF_NEED_RESCHED flag is
 +	 * stored negated in the top word of the thread_info::preempt_count
 +	 * field)
  	 */
 -	.macro		cond_yield, lbl:req, tmp:req
 -#ifdef CONFIG_PREEMPTION
 +	.macro		cond_yield, lbl:req, tmp:req, tmp2:req
  	get_current_task \tmp
  	ldr		\tmp, [\tmp, #TSK_TI_PREEMPT]
 +	/*
 +	 * If we are serving a softirq, there is no point in yielding: the
 +	 * softirq will not be preempted no matter what we do, so we should
 +	 * run to completion as quickly as we can.
 +	 */
 +	tbnz		\tmp, #SOFTIRQ_SHIFT, .Lnoyield_\@
 +#ifdef CONFIG_PREEMPTION
  	sub		\tmp, \tmp, #PREEMPT_DISABLE_OFFSET
  	cbz		\tmp, \lbl
  #endif

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

^ permalink raw reply	[flat|nested] 83+ messages in thread
* linux-next: manual merge of the kvm-arm tree with the arm64 tree
@ 2021-01-27  5:24 Stephen Rothwell
  0 siblings, 0 replies; 83+ messages in thread
From: Stephen Rothwell @ 2021-01-27  5:24 UTC (permalink / raw)
  To: Christoffer Dall, Marc Zyngier, Catalin Marinas, Will Deacon
  Cc: David Brazdil, Linux Kernel Mailing List, Linux Next Mailing List

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

Hi all,

Today's linux-next merge of the kvm-arm tree got a conflict in:

  arch/arm64/include/asm/kvm_asm.h

between commit:

  7001d4af926b ("arm64: Drop workaround for broken 'S' constraint with GCC 4.9")

from the arm64 tree and commit:

  247bc166e6b3 ("KVM: arm64: Remove hyp_symbol_addr")

from the kvm-arm tree.

I fixed it up (the latter removed the code updated by the former) 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

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

^ permalink raw reply	[flat|nested] 83+ messages in thread
* linux-next: manual merge of the kvm-arm tree with the arm64 tree
@ 2020-12-04  5:44 Stephen Rothwell
  2020-12-04 11:12 ` Marc Zyngier
  0 siblings, 1 reply; 83+ messages in thread
From: Stephen Rothwell @ 2020-12-04  5:44 UTC (permalink / raw)
  To: Christoffer Dall, Marc Zyngier, Catalin Marinas, Will Deacon
  Cc: David Brazdil, Linux Kernel Mailing List,
	Linux Next Mailing List, Mark Rutland

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

Hi all,

Today's linux-next merge of the kvm-arm tree got a conflict in:

  arch/arm64/kernel/head.S

between commits:

  2ffac9e3fdbd ("arm64: head.S: cleanup SCTLR_ELx initialization")
  d87a8e65b510 ("arm64: head.S: always initialize PSTATE")

from the arm64 tree and commit:

  9c322020286c ("arm64: Extract parts of el2_setup into a macro")

from the kvm-arm tree.

I have no idea how to fix this up, so I just used the kvm-arm tree from
next-20201203 instead for today.

-- 
Cheers,
Stephen Rothwell

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

^ permalink raw reply	[flat|nested] 83+ messages in thread
* linux-next: manual merge of the kvm-arm tree with the arm64 tree
@ 2020-12-04  5:17 Stephen Rothwell
  0 siblings, 0 replies; 83+ messages in thread
From: Stephen Rothwell @ 2020-12-04  5:17 UTC (permalink / raw)
  To: Christoffer Dall, Marc Zyngier, Catalin Marinas, Will Deacon
  Cc: David Brazdil, Linux Kernel Mailing List, Linux Next Mailing List

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

Hi all,

Today's linux-next merge of the kvm-arm tree got a conflict in:

  arch/arm64/include/asm/cpucaps.h

between commit:

  364a5a8ae8dc ("arm64: cpufeatures: Add capability for LDAPR instruction")

from the arm64 tree and commit:

  44e88d43c442 ("KVM: arm64: Add ARM64_KVM_PROTECTED_MODE CPU capability")

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 a7242ef2a2cd,42f850718d4b..000000000000
--- a/arch/arm64/include/asm/cpucaps.h
+++ b/arch/arm64/include/asm/cpucaps.h
@@@ -64,8 -66,8 +64,9 @@@
  #define ARM64_HAS_TLB_RANGE			56
  #define ARM64_MTE				57
  #define ARM64_WORKAROUND_1508412		58
 -#define ARM64_KVM_PROTECTED_MODE		59
 +#define ARM64_HAS_LDAPR				59
++#define ARM64_KVM_PROTECTED_MODE		60
  
--#define ARM64_NCAPS				60
++#define ARM64_NCAPS				61
  
  #endif /* __ASM_CPUCAPS_H */

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

^ permalink raw reply	[flat|nested] 83+ messages in thread
* linux-next: manual merge of the kvm-arm tree with the arm64 tree
@ 2020-09-30  6:26 Stephen Rothwell
  0 siblings, 0 replies; 83+ messages in thread
From: Stephen Rothwell @ 2020-09-30  6:26 UTC (permalink / raw)
  To: Christoffer Dall, Marc Zyngier, Catalin Marinas, Will Deacon
  Cc: Linux Next Mailing List, Linux Kernel Mailing List

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

Hi all,

Today's linux-next merge of the kvm-arm tree got a conflict in:

  arch/arm64/kvm/hyp/Makefile

between commit:

  5359a87d5bda ("KVM: arm64: Replace CONFIG_KVM_INDIRECT_VECTORS with CONFIG_RANDOMIZE_BASE")
  9ef2b48be9bb ("KVM: arm64: Allow patching EL2 vectors even with KASLR is not enabled")

from the arm64 tree and commit:

  b1e57de62cfb ("KVM: arm64: Add stand-alone page-table walker infrastructure")

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/kvm/hyp/Makefile
index d898f0da5802,607b8a898826..000000000000
--- a/arch/arm64/kvm/hyp/Makefile
+++ b/arch/arm64/kvm/hyp/Makefile
@@@ -10,4 -10,5 +10,4 @@@ subdir-ccflags-y := -I$(incdir)				
  		    -DDISABLE_BRANCH_PROFILING		\
  		    $(DISABLE_STACKLEAK_PLUGIN)
  
- obj-$(CONFIG_KVM) += vhe/ nvhe/ smccc_wa.o
 -obj-$(CONFIG_KVM) += vhe/ nvhe/ pgtable.o
 -obj-$(CONFIG_KVM_INDIRECT_VECTORS) += smccc_wa.o
++obj-$(CONFIG_KVM) += vhe/ nvhe/ smccc_wa.o pgtable.o

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

^ permalink raw reply	[flat|nested] 83+ messages in thread
* linux-next: manual merge of the kvm-arm tree with the arm64 tree
@ 2020-05-29  7:00 Stephen Rothwell
  0 siblings, 0 replies; 83+ messages in thread
From: Stephen Rothwell @ 2020-05-29  7:00 UTC (permalink / raw)
  To: Christoffer Dall, Marc Zyngier, Catalin Marinas, Will Deacon
  Cc: Linux Next Mailing List, Linux Kernel Mailing List, Dave Martin

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

Hi all,

Today's linux-next merge of the kvm-arm tree got a conflict in:

  arch/arm64/include/asm/ptrace.h

between commit:

  8ef8f360cf30 ("arm64: Basic Branch Target Identification support")

from the arm64 tree and commit:

  d9d7d84d9906 ("KVM: arm64: Parametrize exception entry with a target EL")

from the kvm-arm tree.

I fixed it up (I used the latter - the former just added a blank line)
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

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

^ permalink raw reply	[flat|nested] 83+ messages in thread
* linux-next: manual merge of the kvm-arm tree with the arm64 tree
@ 2019-07-08  7:24 Stephen Rothwell
  0 siblings, 0 replies; 83+ messages in thread
From: Stephen Rothwell @ 2019-07-08  7:24 UTC (permalink / raw)
  To: Christoffer Dall, Marc Zyngier, Catalin Marinas, Will Deacon
  Cc: Linux Next Mailing List, Linux Kernel Mailing List,
	Julien Thierry, Andre Przywara

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

Hi all,

Today's linux-next merge of the kvm-arm tree got a conflict in:

  arch/arm64/include/asm/cpufeature.h

between commit:

  48ce8f80f590 ("arm64: irqflags: Introduce explicit debugging for IRQ priorities")

from the arm64 tree and commit:

  c118bbb52743 ("arm64: KVM: Propagate full Spectre v2 workaround state to KVM guests")

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/cpufeature.h
index 3d8db50d9ae2,948427f6b3d9..000000000000
--- a/arch/arm64/include/asm/cpufeature.h
+++ b/arch/arm64/include/asm/cpufeature.h
@@@ -614,12 -614,12 +614,18 @@@ static inline bool system_uses_irq_prio
  	       cpus_have_const_cap(ARM64_HAS_IRQ_PRIO_MASKING);
  }
  
 +static inline bool system_has_prio_mask_debugging(void)
 +{
 +	return IS_ENABLED(CONFIG_ARM64_DEBUG_PRIORITY_MASKING) &&
 +	       system_uses_irq_prio_masking();
 +}
 +
+ #define ARM64_BP_HARDEN_UNKNOWN		-1
+ #define ARM64_BP_HARDEN_WA_NEEDED	0
+ #define ARM64_BP_HARDEN_NOT_REQUIRED	1
+ 
+ int get_spectre_v2_workaround_state(void);
+ 
  #define ARM64_SSBD_UNKNOWN		-1
  #define ARM64_SSBD_FORCE_DISABLE	0
  #define ARM64_SSBD_KERNEL		1

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

^ permalink raw reply	[flat|nested] 83+ messages in thread
* linux-next: manual merge of the kvm-arm tree with the arm64 tree
@ 2018-10-04  4:22 Stephen Rothwell
  0 siblings, 0 replies; 83+ messages in thread
From: Stephen Rothwell @ 2018-10-04  4:22 UTC (permalink / raw)
  To: Christoffer Dall, Marc Zyngier
  Cc: Linux-Next Mailing List, Linux Kernel Mailing List,
	Suzuki K Poulose, Vladimir Murzin

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

Hi all,

Today's linux-next merge of the kvm-arm tree got conflicts in:

  arch/arm/include/asm/kvm_mmu.h
  arch/arm64/include/asm/kvm_arm.h
  arch/arm64/include/asm/kvm_mmu.h

between commit:

  ab510027dc4d ("arm64: KVM: Enable Common Not Private translations")

from the arm64 tree and commit:

  0f62f0e95be2 ("kvm: arm64: Set a limit on the IPA size")
  595583306434 ("kvm: arm64: Dynamic configuration of VTTBR mask")

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/arm/include/asm/kvm_mmu.h
index 847f01fa429d,5ad1a54f98dc..000000000000
--- a/arch/arm/include/asm/kvm_mmu.h
+++ b/arch/arm/include/asm/kvm_mmu.h
@@@ -355,11 -358,8 +358,13 @@@ static inline int hyp_map_aux_data(void
  
  #define kvm_phys_to_vttbr(addr)		(addr)
  
 +static inline bool kvm_cpu_has_cnp(void)
 +{
 +	return false;
 +}
 +
+ static inline void kvm_set_ipa_limit(void) {}
+ 
  #endif	/* !__ASSEMBLY__ */
  
  #endif /* __ARM_KVM_MMU_H__ */
diff --cc arch/arm64/include/asm/kvm_arm.h
index b476bc46f0ab,6e324d1f1231..000000000000
--- a/arch/arm64/include/asm/kvm_arm.h
+++ b/arch/arm64/include/asm/kvm_arm.h
@@@ -145,38 -143,127 +143,128 @@@
  #define VTCR_EL2_COMMON_BITS	(VTCR_EL2_SH0_INNER | VTCR_EL2_ORGN0_WBWA | \
  				 VTCR_EL2_IRGN0_WBWA | VTCR_EL2_RES1)
  
- #ifdef CONFIG_ARM64_64K_PAGES
  /*
-  * Stage2 translation configuration:
-  * 64kB pages (TG0 = 1)
-  * 2 level page tables (SL = 1)
+  * VTCR_EL2:SL0 indicates the entry level for Stage2 translation.
+  * Interestingly, it depends on the page size.
+  * See D.10.2.121, VTCR_EL2, in ARM DDI 0487C.a
+  *
+  *	-----------------------------------------
+  *	| Entry level		|  4K  | 16K/64K |
+  *	------------------------------------------
+  *	| Level: 0		|  2   |   -     |
+  *	------------------------------------------
+  *	| Level: 1		|  1   |   2     |
+  *	------------------------------------------
+  *	| Level: 2		|  0   |   1     |
+  *	------------------------------------------
+  *	| Level: 3		|  -   |   0     |
+  *	------------------------------------------
+  *
+  * The table roughly translates to :
+  *
+  *	SL0(PAGE_SIZE, Entry_level) = TGRAN_SL0_BASE - Entry_Level
+  *
+  * Where TGRAN_SL0_BASE is a magic number depending on the page size:
+  * 	TGRAN_SL0_BASE(4K) = 2
+  *	TGRAN_SL0_BASE(16K) = 3
+  *	TGRAN_SL0_BASE(64K) = 3
+  * provided we take care of ruling out the unsupported cases and
+  * Entry_Level = 4 - Number_of_levels.
+  *
   */
- #define VTCR_EL2_TGRAN_FLAGS		(VTCR_EL2_TG0_64K | VTCR_EL2_SL0_LVL1)
- #define VTTBR_X_TGRAN_MAGIC		38
+ #ifdef CONFIG_ARM64_64K_PAGES
+ 
+ #define VTCR_EL2_TGRAN			VTCR_EL2_TG0_64K
+ #define VTCR_EL2_TGRAN_SL0_BASE		3UL
+ 
  #elif defined(CONFIG_ARM64_16K_PAGES)
- /*
-  * Stage2 translation configuration:
-  * 16kB pages (TG0 = 2)
-  * 2 level page tables (SL = 1)
-  */
- #define VTCR_EL2_TGRAN_FLAGS		(VTCR_EL2_TG0_16K | VTCR_EL2_SL0_LVL1)
- #define VTTBR_X_TGRAN_MAGIC		42
+ 
+ #define VTCR_EL2_TGRAN			VTCR_EL2_TG0_16K
+ #define VTCR_EL2_TGRAN_SL0_BASE		3UL
+ 
  #else	/* 4K */
- /*
-  * Stage2 translation configuration:
-  * 4kB pages (TG0 = 0)
-  * 3 level page tables (SL = 1)
-  */
- #define VTCR_EL2_TGRAN_FLAGS		(VTCR_EL2_TG0_4K | VTCR_EL2_SL0_LVL1)
- #define VTTBR_X_TGRAN_MAGIC		37
+ 
+ #define VTCR_EL2_TGRAN			VTCR_EL2_TG0_4K
+ #define VTCR_EL2_TGRAN_SL0_BASE		2UL
+ 
  #endif
  
- #define VTCR_EL2_FLAGS			(VTCR_EL2_COMMON_BITS | VTCR_EL2_TGRAN_FLAGS)
- #define VTTBR_X				(VTTBR_X_TGRAN_MAGIC - VTCR_EL2_T0SZ_IPA)
+ #define VTCR_EL2_LVLS_TO_SL0(levels)	\
+ 	((VTCR_EL2_TGRAN_SL0_BASE - (4 - (levels))) << VTCR_EL2_SL0_SHIFT)
+ #define VTCR_EL2_SL0_TO_LVLS(sl0)	\
+ 	((sl0) + 4 - VTCR_EL2_TGRAN_SL0_BASE)
+ #define VTCR_EL2_LVLS(vtcr)		\
+ 	VTCR_EL2_SL0_TO_LVLS(((vtcr) & VTCR_EL2_SL0_MASK) >> VTCR_EL2_SL0_SHIFT)
+ 
+ #define VTCR_EL2_FLAGS			(VTCR_EL2_COMMON_BITS | VTCR_EL2_TGRAN)
+ #define VTCR_EL2_IPA(vtcr)		(64 - ((vtcr) & VTCR_EL2_T0SZ_MASK))
+ 
+ /*
+  * ARM VMSAv8-64 defines an algorithm for finding the translation table
+  * descriptors in section D4.2.8 in ARM DDI 0487C.a.
+  *
+  * The algorithm defines the expectations on the translation table
+  * addresses for each level, based on PAGE_SIZE, entry level
+  * and the translation table size (T0SZ). The variable "x" in the
+  * algorithm determines the alignment of a table base address at a given
+  * level and thus determines the alignment of VTTBR:BADDR for stage2
+  * page table entry level.
+  * Since the number of bits resolved at the entry level could vary
+  * depending on the T0SZ, the value of "x" is defined based on a
+  * Magic constant for a given PAGE_SIZE and Entry Level. The
+  * intermediate levels must be always aligned to the PAGE_SIZE (i.e,
+  * x = PAGE_SHIFT).
+  *
+  * The value of "x" for entry level is calculated as :
+  *    x = Magic_N - T0SZ
+  *
+  * where Magic_N is an integer depending on the page size and the entry
+  * level of the page table as below:
+  *
+  *	--------------------------------------------
+  *	| Entry level		|  4K    16K   64K |
+  *	--------------------------------------------
+  *	| Level: 0 (4 levels)	| 28   |  -  |  -  |
+  *	--------------------------------------------
+  *	| Level: 1 (3 levels)	| 37   | 31  | 25  |
+  *	--------------------------------------------
+  *	| Level: 2 (2 levels)	| 46   | 42  | 38  |
+  *	--------------------------------------------
+  *	| Level: 3 (1 level)	| -    | 53  | 51  |
+  *	--------------------------------------------
+  *
+  * We have a magic formula for the Magic_N below:
+  *
+  *  Magic_N(PAGE_SIZE, Level) = 64 - ((PAGE_SHIFT - 3) * Number_of_levels)
+  *
+  * where Number_of_levels = (4 - Level). We are only interested in the
+  * value for Entry_Level for the stage2 page table.
+  *
+  * So, given that T0SZ = (64 - IPA_SHIFT), we can compute 'x' as follows:
+  *
+  *	x = (64 - ((PAGE_SHIFT - 3) * Number_of_levels)) - (64 - IPA_SHIFT)
+  *	  = IPA_SHIFT - ((PAGE_SHIFT - 3) * Number of levels)
+  *
+  * Here is one way to explain the Magic Formula:
+  *
+  *  x = log2(Size_of_Entry_Level_Table)
+  *
+  * Since, we can resolve (PAGE_SHIFT - 3) bits at each level, and another
+  * PAGE_SHIFT bits in the PTE, we have :
+  *
+  *  Bits_Entry_level = IPA_SHIFT - ((PAGE_SHIFT - 3) * (n - 1) + PAGE_SHIFT)
+  *		     = IPA_SHIFT - (PAGE_SHIFT - 3) * n - 3
+  *  where n = number of levels, and since each pointer is 8bytes, we have:
+  *
+  *  x = Bits_Entry_Level + 3
+  *    = IPA_SHIFT - (PAGE_SHIFT - 3) * n
+  *
+  * The only constraint here is that, we have to find the number of page table
+  * levels for a given IPA size (which we do, see stage2_pt_levels())
+  */
+ #define ARM64_VTTBR_X(ipa, levels)	((ipa) - ((levels) * (PAGE_SHIFT - 3)))
  
 +#define VTTBR_CNP_BIT     (UL(1))
- #define VTTBR_BADDR_MASK  (((UL(1) << (PHYS_MASK_SHIFT - VTTBR_X)) - 1) << VTTBR_X)
  #define VTTBR_VMID_SHIFT  (UL(48))
  #define VTTBR_VMID_MASK(size) (_AT(u64, (1 << size) - 1) << VTTBR_VMID_SHIFT)
  
diff --cc arch/arm64/include/asm/kvm_mmu.h
index 64337afbf124,77b1af9e64db..000000000000
--- a/arch/arm64/include/asm/kvm_mmu.h
+++ b/arch/arm64/include/asm/kvm_mmu.h
@@@ -517,10 -519,29 +519,34 @@@ static inline int hyp_map_aux_data(void
  
  #define kvm_phys_to_vttbr(addr)		phys_to_ttbr(addr)
  
 +static inline bool kvm_cpu_has_cnp(void)
 +{
 +	return system_supports_cnp();
 +}
 +
+ /*
+  * Get the magic number 'x' for VTTBR:BADDR of this KVM instance.
+  * With v8.2 LVA extensions, 'x' should be a minimum of 6 with
+  * 52bit IPS.
+  */
+ static inline int arm64_vttbr_x(u32 ipa_shift, u32 levels)
+ {
+ 	int x = ARM64_VTTBR_X(ipa_shift, levels);
+ 
+ 	return (IS_ENABLED(CONFIG_ARM64_PA_BITS_52) && x < 6) ? 6 : x;
+ }
+ 
+ static inline u64 vttbr_baddr_mask(u32 ipa_shift, u32 levels)
+ {
+ 	unsigned int x = arm64_vttbr_x(ipa_shift, levels);
+ 
+ 	return GENMASK_ULL(PHYS_MASK_SHIFT - 1, x);
+ }
+ 
+ static inline u64 kvm_vttbr_baddr_mask(struct kvm *kvm)
+ {
+ 	return vttbr_baddr_mask(kvm_phys_shift(kvm), kvm_stage2_levels(kvm));
+ }
+ 
  #endif /* __ASSEMBLY__ */
  #endif /* __ARM64_KVM_MMU_H__ */

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

^ permalink raw reply	[flat|nested] 83+ messages in thread
* linux-next: manual merge of the kvm-arm tree with the arm64 tree
@ 2018-10-04  4:07 Stephen Rothwell
  0 siblings, 0 replies; 83+ messages in thread
From: Stephen Rothwell @ 2018-10-04  4:07 UTC (permalink / raw)
  To: Christoffer Dall, Marc Zyngier
  Cc: Linux-Next Mailing List, Linux Kernel Mailing List,
	Suzuki K Poulose, Anshuman Khandual

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

Hi all,

Today's linux-next merge of the kvm-arm tree got a conflict in:

  arch/arm64/include/asm/cpufeature.h

between commit:

  520ad98871a0 ("arm64/cpufeatures: Factorize emulate_mrs()")

from the arm64 tree and commit:

  ce00e3cb4fb4 ("arm64: Add a helper for PARange to physical shift conversion")

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/cpufeature.h
index 6db48d90ad63,072cc1c970c2..000000000000
--- a/arch/arm64/include/asm/cpufeature.h
+++ b/arch/arm64/include/asm/cpufeature.h
@@@ -536,7 -530,26 +536,28 @@@ void arm64_set_ssbd_mitigation(bool sta
  static inline void arm64_set_ssbd_mitigation(bool state) {}
  #endif
  
+ static inline u32 id_aa64mmfr0_parange_to_phys_shift(int parange)
+ {
+ 	switch (parange) {
+ 	case 0: return 32;
+ 	case 1: return 36;
+ 	case 2: return 40;
+ 	case 3: return 42;
+ 	case 4: return 44;
+ 	case 5: return 48;
+ 	case 6: return 52;
+ 	/*
+ 	 * A future PE could use a value unknown to the kernel.
+ 	 * However, by the "D10.1.4 Principles of the ID scheme
+ 	 * for fields in ID registers", ARM DDI 0487C.a, any new
+ 	 * value is guaranteed to be higher than what we know already.
+ 	 * As a safe limit, we return the limit supported by the kernel.
+ 	 */
+ 	default: return CONFIG_ARM64_PA_BITS;
+ 	}
+ }
++
 +extern int do_emulate_mrs(struct pt_regs *regs, u32 sys_reg, u32 rt);
  #endif /* __ASSEMBLY__ */
  
  #endif

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

^ permalink raw reply	[flat|nested] 83+ messages in thread
* linux-next: manual merge of the kvm-arm tree with the arm64 tree
@ 2018-07-23  4:46 Stephen Rothwell
  2018-07-23 10:45 ` Marc Zyngier
  2018-08-16  0:15 ` Stephen Rothwell
  0 siblings, 2 replies; 83+ messages in thread
From: Stephen Rothwell @ 2018-07-23  4:46 UTC (permalink / raw)
  To: Christoffer Dall, Marc Zyngier, Catalin Marinas, Will Deacon
  Cc: Linux-Next Mailing List, Linux Kernel Mailing List, Suzuki K Poulose

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

Hi all,

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 */

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

^ permalink raw reply	[flat|nested] 83+ messages in thread
* linux-next: manual merge of the kvm-arm tree with the arm64 tree
@ 2018-06-01  6:23 Stephen Rothwell
  2018-06-01  8:23 ` Marc Zyngier
  0 siblings, 1 reply; 83+ messages in thread
From: Stephen Rothwell @ 2018-06-01  6:23 UTC (permalink / raw)
  To: Christoffer Dall, Marc Zyngier, Catalin Marinas, Will Deacon
  Cc: Linux-Next Mailing List, Linux Kernel Mailing List, Dave Martin

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

Hi all,

Today's linux-next merge of the kvm-arm tree got conflicts in:

  arch/arm64/include/asm/kvm_host.h
  arch/arm64/kvm/hyp/switch.c

between commit:

  55e3748e8902 ("arm64: KVM: Add ARCH_WORKAROUND_2 support for guests")

from the arm64 tree and commits:

  fa89d31c5306 ("KVM: arm64: Repurpose vcpu_arch.debug_flags for general-purpose flags")
  e6b673b741ea ("KVM: arm64: Optimise FPSIMD handling to reduce guest/host thrashing")

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/kvm_host.h
index 95d8a0e15b5f,a4ca202ff3f2..000000000000
--- a/arch/arm64/include/asm/kvm_host.h
+++ b/arch/arm64/include/asm/kvm_host.h
@@@ -216,11 -217,8 +217,11 @@@ struct kvm_vcpu_arch 
  	/* Exception Information */
  	struct kvm_vcpu_fault_info fault;
  
 +	/* State of various workarounds, see kvm_asm.h for bit assignment */
 +	u64 workaround_flags;
 +
- 	/* Guest debug state */
- 	u64 debug_flags;
+ 	/* Miscellaneous vcpu state flags */
+ 	u64 flags;
  
  	/*
  	 * We maintain more than a single set of debug registers to support
diff --cc arch/arm64/kvm/hyp/switch.c
index c50cedc447f1,2d45bd719a5d..000000000000
--- a/arch/arm64/kvm/hyp/switch.c
+++ b/arch/arm64/kvm/hyp/switch.c
@@@ -452,10 -475,6 +511,8 @@@ int kvm_vcpu_run_vhe(struct kvm_vcpu *v
  		/* And we're baaack! */
  	} while (fixup_guest_exit(vcpu, &exit_code));
  
 +	__set_host_arch_workaround_state(vcpu);
 +
- 	fp_enabled = fpsimd_enabled_vhe();
- 
  	sysreg_save_guest_state_vhe(guest_ctxt);
  
  	__deactivate_traps(vcpu);
@@@ -512,10 -525,6 +565,8 @@@ int __hyp_text __kvm_vcpu_run_nvhe(stru
  		/* And we're baaack! */
  	} while (fixup_guest_exit(vcpu, &exit_code));
  
 +	__set_host_arch_workaround_state(vcpu);
 +
- 	fp_enabled = __fpsimd_enabled_nvhe();
- 
  	__sysreg_save_state_nvhe(guest_ctxt);
  	__sysreg32_save_state(vcpu);
  	__timer_disable_traps(vcpu);

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

^ permalink raw reply	[flat|nested] 83+ messages in thread
* linux-next: manual merge of the kvm-arm tree with the arm64 tree
@ 2018-06-01  6:13 Stephen Rothwell
  0 siblings, 0 replies; 83+ messages in thread
From: Stephen Rothwell @ 2018-06-01  6:13 UTC (permalink / raw)
  To: Christoffer Dall, Marc Zyngier, Catalin Marinas, Will Deacon
  Cc: Linux-Next Mailing List, Linux Kernel Mailing List, Dave Martin

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

Hi all,

Today's linux-next merge of the kvm-arm tree got a conflict in:

  arch/arm64/include/asm/cpufeature.h

between commits:

  a43ae4dfe56a ("arm64: Add 'ssbd' command-line option")
  c32e1736ca03 ("arm64: ssbd: Add global mitigation state accessor")
  647d0519b53f ("arm64: ssbd: Restore mitigation status on CPU resume")

from the arm64 tree and commit:

  31dc52b3c8fa ("arm64/sve: Move read_zcr_features() out of cpufeature.h")

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/cpufeature.h
index 55bc1f073bfb,0a6b7133195e..000000000000
--- a/arch/arm64/include/asm/cpufeature.h
+++ b/arch/arm64/include/asm/cpufeature.h
@@@ -510,55 -508,6 +508,28 @@@ static inline bool system_supports_sve(
  		cpus_have_const_cap(ARM64_SVE);
  }
  
- /*
-  * Read the pseudo-ZCR used by cpufeatures to identify the supported SVE
-  * vector length.
-  *
-  * Use only if SVE is present.
-  * This function clobbers the SVE vector length.
-  */
- static inline u64 read_zcr_features(void)
- {
- 	u64 zcr;
- 	unsigned int vq_max;
- 
- 	/*
- 	 * Set the maximum possible VL, and write zeroes to all other
- 	 * bits to see if they stick.
- 	 */
- 	sve_kernel_enable(NULL);
- 	write_sysreg_s(ZCR_ELx_LEN_MASK, SYS_ZCR_EL1);
- 
- 	zcr = read_sysreg_s(SYS_ZCR_EL1);
- 	zcr &= ~(u64)ZCR_ELx_LEN_MASK; /* find sticky 1s outside LEN field */
- 	vq_max = sve_vq_from_vl(sve_get_vl());
- 	zcr |= vq_max - 1; /* set LEN field to maximum effective value */
- 
- 	return zcr;
- }
- 
 +#define ARM64_SSBD_UNKNOWN		-1
 +#define ARM64_SSBD_FORCE_DISABLE	0
 +#define ARM64_SSBD_KERNEL		1
 +#define ARM64_SSBD_FORCE_ENABLE		2
 +#define ARM64_SSBD_MITIGATED		3
 +
 +static inline int arm64_get_ssbd_state(void)
 +{
 +#ifdef CONFIG_ARM64_SSBD
 +	extern int ssbd_state;
 +	return ssbd_state;
 +#else
 +	return ARM64_SSBD_UNKNOWN;
 +#endif
 +}
 +
 +#ifdef CONFIG_ARM64_SSBD
 +void arm64_set_ssbd_mitigation(bool state);
 +#else
 +static inline void arm64_set_ssbd_mitigation(bool state) {}
 +#endif
 +
  #endif /* __ASSEMBLY__ */
  
  #endif

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

^ permalink raw reply	[flat|nested] 83+ messages in thread
* linux-next: manual merge of the kvm-arm tree with the arm64 tree
@ 2018-03-28  5:05 Stephen Rothwell
  2018-03-29  5:16 ` Stephen Rothwell
  0 siblings, 1 reply; 83+ messages in thread
From: Stephen Rothwell @ 2018-03-28  5:05 UTC (permalink / raw)
  To: Christoffer Dall, Marc Zyngier, Catalin Marinas, Will Deacon
  Cc: Linux-Next Mailing List, Linux Kernel Mailing List, Suzuki K Poulose

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

Hi all,

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);

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

^ permalink raw reply	[flat|nested] 83+ messages in thread
* linux-next: manual merge of the kvm-arm tree with the arm64 tree
@ 2017-08-25  4:57 Stephen Rothwell
  2017-08-25  8:11 ` Marc Zyngier
  0 siblings, 1 reply; 83+ messages in thread
From: Stephen Rothwell @ 2017-08-25  4:57 UTC (permalink / raw)
  To: Christoffer Dall, Marc Zyngier, Catalin Marinas
  Cc: Linux-Next Mailing List, Linux Kernel Mailing List, James Morse,
	Julien Thierry

Hi all,

Today's linux-next merge of the kvm-arm tree got a conflict in:

  arch/arm64/include/asm/esr.h

between commit:

  1f9b8936f36f ("arm64: Decode information from ESR upon mem faults")

from the arm64 tree and commit:

  c5511c3c068c ("KVM: arm/arm64: Fix guest external abort matching")

from the kvm-arm tree.

I fixed it up (I used the former version) 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

^ permalink raw reply	[flat|nested] 83+ messages in thread
* linux-next: manual merge of the kvm-arm tree with the arm64 tree
@ 2016-02-29  5:18 Stephen Rothwell
  0 siblings, 0 replies; 83+ messages in thread
From: Stephen Rothwell @ 2016-02-29  5:18 UTC (permalink / raw)
  To: Christoffer Dall, Marc Zyngier, Catalin Marinas
  Cc: linux-next, linux-kernel, Andrew Pinski

Hi all,

Today's linux-next merge of the kvm-arm tree got a conflict in:

  arch/arm64/include/asm/cpufeature.h

between commit:

  104a0c02e8b1 ("arm64: Add workaround for Cavium erratum 27456")

from the arm64 tree and commit:

  d0be74f771d5 ("arm64: Add ARM64_HAS_VIRT_HOST_EXTN feature")

from the kvm-arm tree.

I fixed it up (see below) and can carry the fix as necessary (no action
is required).

-- 
Cheers,
Stephen Rothwell

diff --cc arch/arm64/include/asm/cpufeature.h
index 1497163213ed,a5c769b1c65b..000000000000
--- a/arch/arm64/include/asm/cpufeature.h
+++ b/arch/arm64/include/asm/cpufeature.h
@@@ -30,12 -30,12 +30,13 @@@
  #define ARM64_HAS_LSE_ATOMICS			5
  #define ARM64_WORKAROUND_CAVIUM_23154		6
  #define ARM64_WORKAROUND_834220			7
 -/* #define ARM64_HAS_NO_HW_PREFETCH		8 */
 -/* #define ARM64_HAS_UAO			9 */
 -/* #define ARM64_ALT_PAN_NOT_UAO		10 */
 +#define ARM64_HAS_NO_HW_PREFETCH		8
 +#define ARM64_HAS_UAO				9
 +#define ARM64_ALT_PAN_NOT_UAO			10
+ #define ARM64_HAS_VIRT_HOST_EXTN		11
 +#define ARM64_WORKAROUND_CAVIUM_27456		12
  
 -#define ARM64_NCAPS				12
 +#define ARM64_NCAPS				13
  
  #ifndef __ASSEMBLY__
  

^ permalink raw reply	[flat|nested] 83+ messages in thread
* linux-next: manual merge of the kvm-arm tree with the arm64 tree
@ 2016-02-24  2:38 Stephen Rothwell
  0 siblings, 0 replies; 83+ messages in thread
From: Stephen Rothwell @ 2016-02-24  2:38 UTC (permalink / raw)
  To: Christoffer Dall, Marc Zyngier, Catalin Marinas
  Cc: linux-next, linux-kernel, Ard Biesheuvel

Hi all,

Today's linux-next merge of the kvm-arm tree got a conflict in:

  arch/arm64/include/asm/kvm_host.h

between commit:

  a0bf9776cd0b ("arm64: kvm: deal with kernel symbols outside of linear mapping")

from the arm64 tree and commit:

  67aaab4cff18 ("arm64: KVM: Move __cpu_init_stage2 after kvm_call_hyp")

from the kvm-arm tree.

This was an expected conflict (see the kvm-arm tree commit message.

I fixed it up (as expected - see below) and can carry the fix as necessary
(no action is required).

-- 
Cheers,
Stephen Rothwell

diff --cc arch/arm64/include/asm/kvm_host.h
index e3d67ff8798b,31fe7d6f32de..000000000000
--- a/arch/arm64/include/asm/kvm_host.h
+++ b/arch/arm64/include/asm/kvm_host.h
@@@ -343,6 -344,11 +344,11 @@@ void kvm_arm_setup_debug(struct kvm_vcp
  void kvm_arm_clear_debug(struct kvm_vcpu *vcpu);
  void kvm_arm_reset_debug_ptr(struct kvm_vcpu *vcpu);
  
 -/* #define kvm_call_hyp(f, ...) __kvm_call_hyp(kvm_ksym_ref(f), ##__VA_ARGS__) */
 +#define kvm_call_hyp(f, ...) __kvm_call_hyp(kvm_ksym_ref(f), ##__VA_ARGS__)
  
+ static inline void __cpu_init_stage2(void)
+ {
+ 	kvm_call_hyp(__init_stage2_translation);
+ }
+ 
  #endif /* __ARM64_KVM_HOST_H__ */

^ permalink raw reply	[flat|nested] 83+ messages in thread
* linux-next: manual merge of the kvm-arm tree with the arm64 tree
@ 2016-02-22  2:33 Stephen Rothwell
  2016-02-22  9:26 ` Catalin Marinas
  0 siblings, 1 reply; 83+ messages in thread
From: Stephen Rothwell @ 2016-02-22  2:33 UTC (permalink / raw)
  To: Christoffer Dall, Marc Zyngier, Catalin Marinas
  Cc: linux-next, linux-kernel, Ard Biesheuvel

Hi all,

Today's linux-next merge of the kvm-arm tree got a conflict in:

  arch/arm64/kvm/hyp.S

between commit:

  a0bf9776cd0b ("arm64: kvm: deal with kernel symbols outside of linear mapping")

from the arm64 tree and commit:

  253dcab4c363 ("arm64: KVM: VHE: Patch out use of HVC")

from the kvm-arm tree.

I fixed it up (see below) and can carry the fix as necessary (no action
is required).

-- 
Cheers,
Stephen Rothwell

diff --cc arch/arm64/kvm/hyp.S
index 870578f84b1c,0689a74e6ba0..000000000000
--- a/arch/arm64/kvm/hyp.S
+++ b/arch/arm64/kvm/hyp.S
@@@ -17,10 -17,12 +17,12 @@@
  
  #include <linux/linkage.h>
  
+ #include <asm/alternative.h>
  #include <asm/assembler.h>
+ #include <asm/cpufeature.h>
  
  /*
 - * u64 kvm_call_hyp(void *hypfn, ...);
 + * u64 __kvm_call_hyp(void *hypfn, ...);
   *
   * This is not really a variadic function in the classic C-way and care must
   * be taken when calling this to ensure parameters are passed in registers
@@@ -37,7 -39,12 +39,12 @@@
   * used to implement __hyp_get_vectors in the same way as in
   * arch/arm64/kernel/hyp_stub.S.
   */
 -ENTRY(kvm_call_hyp)
 +ENTRY(__kvm_call_hyp)
+ alternative_if_not ARM64_HAS_VIRT_HOST_EXTN	
  	hvc	#0
  	ret
+ alternative_else
+ 	b	__vhe_hyp_call
+ 	nop
+ alternative_endif
 -ENDPROC(kvm_call_hyp)
 +ENDPROC(__kvm_call_hyp)

^ permalink raw reply	[flat|nested] 83+ messages in thread
* linux-next: manual merge of the kvm-arm tree with the arm64 tree
@ 2016-02-22  2:28 Stephen Rothwell
  2016-02-22  9:24 ` Catalin Marinas
  0 siblings, 1 reply; 83+ messages in thread
From: Stephen Rothwell @ 2016-02-22  2:28 UTC (permalink / raw)
  To: Christoffer Dall, Marc Zyngier, Catalin Marinas
  Cc: linux-next, linux-kernel, Will Deacon, James Morse

Hi all,

Today's linux-next merge of the kvm-arm tree got a conflict in:

  arch/arm64/include/asm/cpufeature.h
  arch/arm64/kernel/cpufeature.c

between commit:

  d5370f754875 ("arm64: prefetch: add alternative pattern for CPUs without a prefetcher")
  57f4959bad0a ("arm64: kernel: Add support for User Access Override")
  705441960033 ("arm64: kernel: Don't toggle PAN on systems with UAO")

from the arm64 tree and commit:

  d0be74f771d5 ("arm64: Add ARM64_HAS_VIRT_HOST_EXTN feature")

from the kvm-arm tree.

I fixed it up (see below) and can carry the fix as necessary (no action
is required).

-- 
Cheers,
Stephen Rothwell

diff --cc arch/arm64/include/asm/cpufeature.h
index 37a53fc6b384,a5c769b1c65b..000000000000
--- a/arch/arm64/include/asm/cpufeature.h
+++ b/arch/arm64/include/asm/cpufeature.h
@@@ -30,11 -30,12 +30,12 @@@
  #define ARM64_HAS_LSE_ATOMICS			5
  #define ARM64_WORKAROUND_CAVIUM_23154		6
  #define ARM64_WORKAROUND_834220			7
 -/* #define ARM64_HAS_NO_HW_PREFETCH		8 */
 -/* #define ARM64_HAS_UAO			9 */
 -/* #define ARM64_ALT_PAN_NOT_UAO		10 */
 +#define ARM64_HAS_NO_HW_PREFETCH		8
 +#define ARM64_HAS_UAO				9
 +#define ARM64_ALT_PAN_NOT_UAO			10
+ #define ARM64_HAS_VIRT_HOST_EXTN		11
  
- #define ARM64_NCAPS				11
+ #define ARM64_NCAPS				12
  
  #ifndef __ASSEMBLY__
  
diff --cc arch/arm64/kernel/cpufeature.c
index 7566cad9fa1d,ba745199297e..000000000000
--- a/arch/arm64/kernel/cpufeature.c
+++ b/arch/arm64/kernel/cpufeature.c
@@@ -634,18 -622,11 +635,23 @@@ static bool has_useable_gicv3_cpuif(con
  	return has_sre;
  }
  
 +static bool has_no_hw_prefetch(const struct arm64_cpu_capabilities *entry)
 +{
 +	u32 midr = read_cpuid_id();
 +	u32 rv_min, rv_max;
 +
 +	/* Cavium ThunderX pass 1.x and 2.x */
 +	rv_min = 0;
 +	rv_max = (1 << MIDR_VARIANT_SHIFT) | MIDR_REVISION_MASK;
 +
 +	return MIDR_IS_CPU_MODEL_RANGE(midr, MIDR_THUNDERX, rv_min, rv_max);
 +}
 +
+ static bool runs_at_el2(const struct arm64_cpu_capabilities *entry)
+ {
+ 	return is_kernel_in_hyp_mode();
+ }
+ 
  static const struct arm64_cpu_capabilities arm64_features[] = {
  	{
  		.desc = "GIC system register CPU interface",
@@@ -677,27 -658,10 +683,32 @@@
  	},
  #endif /* CONFIG_AS_LSE && CONFIG_ARM64_LSE_ATOMICS */
  	{
 +		.desc = "Software prefetching using PRFM",
 +		.capability = ARM64_HAS_NO_HW_PREFETCH,
 +		.matches = has_no_hw_prefetch,
 +	},
 +#ifdef CONFIG_ARM64_UAO
 +	{
 +		.desc = "User Access Override",
 +		.capability = ARM64_HAS_UAO,
 +		.matches = has_cpuid_feature,
 +		.sys_reg = SYS_ID_AA64MMFR2_EL1,
 +		.field_pos = ID_AA64MMFR2_UAO_SHIFT,
 +		.min_field_value = 1,
 +		.enable = cpu_enable_uao,
 +	},
 +#endif /* CONFIG_ARM64_UAO */
 +#ifdef CONFIG_ARM64_PAN
 +	{
 +		.capability = ARM64_ALT_PAN_NOT_UAO,
 +		.matches = cpufeature_pan_not_uao,
 +	},
 +#endif /* CONFIG_ARM64_PAN */
++	{
+ 		.desc = "Virtualization Host Extensions",
+ 		.capability = ARM64_HAS_VIRT_HOST_EXTN,
+ 		.matches = runs_at_el2,
+ 	},
  	{},
  };
  

^ permalink raw reply	[flat|nested] 83+ messages in thread
* linux-next: manual merge of the kvm-arm tree with the arm64 tree
@ 2016-02-12  2:26 Stephen Rothwell
  0 siblings, 0 replies; 83+ messages in thread
From: Stephen Rothwell @ 2016-02-12  2:26 UTC (permalink / raw)
  To: Christoffer Dall, Marc Zyngier, Catalin Marinas
  Cc: linux-next, linux-kernel, Ard Biesheuvel

Hi all,

Today's linux-next merge of the kvm-arm tree got a conflict in:

  arch/arm/kvm/arm.c

between commit:

  6a26b548a2c4 ("arm64: kvm: deal with kernel symbols outside of linear mapping")

from the arm64 tree and commit:

  aa0bf2030bca ("ARM: KVM: Remove __kvm_hyp_code_start/__kvm_hyp_code_end")

from the kvm-arm tree.

I fixed it up (see below) and can carry the fix as necessary (no action
is required).

-- 
Cheers,
Stephen Rothwell

diff --cc arch/arm/kvm/arm.c
index 975da6cfbf59,fcf6c130c986..000000000000
--- a/arch/arm/kvm/arm.c
+++ b/arch/arm/kvm/arm.c
@@@ -982,9 -982,10 +982,10 @@@ static void cpu_init_hyp_mode(void *dum
  	pgd_ptr = kvm_mmu_get_httbr();
  	stack_page = __this_cpu_read(kvm_arm_hyp_stack_page);
  	hyp_stack_ptr = stack_page + PAGE_SIZE;
 -	vector_ptr = (unsigned long)__kvm_hyp_vector;
 +	vector_ptr = (unsigned long)kvm_ksym_ref(__kvm_hyp_vector);
  
  	__cpu_init_hyp_mode(boot_pgd_ptr, pgd_ptr, hyp_stack_ptr, vector_ptr);
+ 	__cpu_init_stage2();
  
  	kvm_arm_init_debug();
  }
@@@ -1074,8 -1075,7 +1075,8 @@@ static int init_hyp_mode(void
  	/*
  	 * Map the Hyp-code called directly from the host
  	 */
- 	err = create_hyp_mappings(kvm_ksym_ref(__kvm_hyp_code_start),
- 				  kvm_ksym_ref(__kvm_hyp_code_end));
 -	err = create_hyp_mappings(__hyp_text_start, __hyp_text_end);
++	err = create_hyp_mappings(kvm_ksym_ref(__hyp_text_start),
++				  kvm_ksym_ref(__hyp_text_end));
  	if (err) {
  		kvm_err("Cannot map world-switch code\n");
  		goto out_free_mappings;

^ permalink raw reply	[flat|nested] 83+ messages in thread
* linux-next: manual merge of the kvm-arm tree with the arm64 tree
@ 2015-01-22  5:07 Stephen Rothwell
  2015-01-22  8:51 ` Marc Zyngier
  0 siblings, 1 reply; 83+ messages in thread
From: Stephen Rothwell @ 2015-01-22  5:07 UTC (permalink / raw)
  To: Christoffer Dall, Marc Zyngier
  Cc: linux-next, linux-kernel, Catalin Marinas, Mark Rutland, Wei Huang

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

Hi all,

Today's linux-next merge of the kvm-arm tree got a conflict in
arch/arm64/include/asm/kvm_arm.h between commit 6e53031ed840 ("arm64:
kvm: remove ESR_EL2_* macros") from the arm64 tree and commit
0d97f8848104 ("arm/arm64: KVM: add tracing support for arm64 exit
handler") from the kvm-arm tree.

I fixed it up (see below, but this probably requires more work) and can
carry the fix as necessary (no action is required).

-- 
Cheers,
Stephen Rothwell                    sfr@canb.auug.org.au

diff --cc arch/arm64/include/asm/kvm_arm.h
index 94674eb7e7bb,3da2d3acec0b..000000000000
--- a/arch/arm64/include/asm/kvm_arm.h
+++ b/arch/arm64/include/asm/kvm_arm.h
@@@ -192,4 -217,46 +192,6 @@@
  /* Hyp Prefetch Fault Address Register (HPFAR/HDFAR) */
  #define HPFAR_MASK	(~UL(0xf))
  
 -#define ESR_EL2_EC_UNKNOWN	(0x00)
 -#define ESR_EL2_EC_WFI		(0x01)
 -#define ESR_EL2_EC_CP15_32	(0x03)
 -#define ESR_EL2_EC_CP15_64	(0x04)
 -#define ESR_EL2_EC_CP14_MR	(0x05)
 -#define ESR_EL2_EC_CP14_LS	(0x06)
 -#define ESR_EL2_EC_FP_ASIMD	(0x07)
 -#define ESR_EL2_EC_CP10_ID	(0x08)
 -#define ESR_EL2_EC_CP14_64	(0x0C)
 -#define ESR_EL2_EC_ILL_ISS	(0x0E)
 -#define ESR_EL2_EC_SVC32	(0x11)
 -#define ESR_EL2_EC_HVC32	(0x12)
 -#define ESR_EL2_EC_SMC32	(0x13)
 -#define ESR_EL2_EC_SVC64	(0x15)
 -#define ESR_EL2_EC_HVC64	(0x16)
 -#define ESR_EL2_EC_SMC64	(0x17)
 -#define ESR_EL2_EC_SYS64	(0x18)
 -#define ESR_EL2_EC_IABT		(0x20)
 -#define ESR_EL2_EC_IABT_HYP	(0x21)
 -#define ESR_EL2_EC_PC_ALIGN	(0x22)
 -#define ESR_EL2_EC_DABT		(0x24)
 -#define ESR_EL2_EC_DABT_HYP	(0x25)
 -#define ESR_EL2_EC_SP_ALIGN	(0x26)
 -#define ESR_EL2_EC_FP_EXC32	(0x28)
 -#define ESR_EL2_EC_FP_EXC64	(0x2C)
 -#define ESR_EL2_EC_SERROR	(0x2F)
 -#define ESR_EL2_EC_BREAKPT	(0x30)
 -#define ESR_EL2_EC_BREAKPT_HYP	(0x31)
 -#define ESR_EL2_EC_SOFTSTP	(0x32)
 -#define ESR_EL2_EC_SOFTSTP_HYP	(0x33)
 -#define ESR_EL2_EC_WATCHPT	(0x34)
 -#define ESR_EL2_EC_WATCHPT_HYP	(0x35)
 -#define ESR_EL2_EC_BKPT32	(0x38)
 -#define ESR_EL2_EC_VECTOR32	(0x3A)
 -#define ESR_EL2_EC_BRK64	(0x3C)
 -
 -#define ESR_EL2_EC_xABT_xFSR_EXTABT	0x10
 -
 -#define ESR_EL2_EC_WFI_ISS_WFE	(1 << 0)
 -
+ #define ESR_EL2_HVC_IMM_MASK	((1UL << 16) - 1)
+ 
  #endif /* __ARM64_KVM_ARM_H__ */

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

^ permalink raw reply	[flat|nested] 83+ messages in thread
* linux-next: manual merge of the kvm-arm tree with the arm64 tree
@ 2015-01-22  5:06 Stephen Rothwell
  0 siblings, 0 replies; 83+ messages in thread
From: Stephen Rothwell @ 2015-01-22  5:06 UTC (permalink / raw)
  To: Christoffer Dall, Marc Zyngier, Catalin Marinas
  Cc: linux-next, linux-kernel, Wei Huang, Mark Rutland

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

Hi all,

Today's linux-next merge of the kvm-arm tree got a conflict in
arch/arm64/kvm/handle_exit.c between commit c6d01a947a51 ("arm64: kvm:
move to ESR_ELx macros") from the arm64 tree and commit 0d97f8848104
("arm/arm64: KVM: add tracing support for arm64 exit handler") from the
kvm-arm tree.

I fixed it up (see below) and can carry the fix as necessary (no action
is required).

-- 
Cheers,
Stephen Rothwell                    sfr@canb.auug.org.au

diff --cc arch/arm64/kvm/handle_exit.c
index 29b184a8f3f8,6a7eb3ce7027..000000000000
--- a/arch/arm64/kvm/handle_exit.c
+++ b/arch/arm64/kvm/handle_exit.c
@@@ -63,10 -67,13 +69,13 @@@ static int handle_smc(struct kvm_vcpu *
   */
  static int kvm_handle_wfx(struct kvm_vcpu *vcpu, struct kvm_run *run)
  {
- 	if (kvm_vcpu_get_hsr(vcpu) & ESR_ELx_WFx_ISS_WFE)
 -	if (kvm_vcpu_get_hsr(vcpu) & ESR_EL2_EC_WFI_ISS_WFE) {
++	if (kvm_vcpu_get_hsr(vcpu) & ESR_ELx_WFx_ISS_WFE) {
+ 		trace_kvm_wfx_arm64(*vcpu_pc(vcpu), true);
  		kvm_vcpu_on_spin(vcpu);
- 	else
+ 	} else {
+ 		trace_kvm_wfx_arm64(*vcpu_pc(vcpu), false);
  		kvm_vcpu_block(vcpu);
+ 	}
  
  	kvm_skip_instr(vcpu, kvm_vcpu_trap_il_is32bit(vcpu));
  

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

^ permalink raw reply	[flat|nested] 83+ messages in thread

end of thread, other threads:[~2024-03-08 12:30 UTC | newest]

Thread overview: 83+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2018-03-28  5:00 linux-next: manual merge of the kvm-arm tree with the arm64 tree Stephen Rothwell
2018-03-28 11:53 ` Will Deacon
  -- strict thread matches above, loose matches on Subject: below --
2024-03-08  1:54 Stephen Rothwell
2024-03-08  6:25 ` Oliver Upton
2024-03-08 12:30   ` Catalin Marinas
2024-03-08  1:47 Stephen Rothwell
2024-02-20  2:21 Stephen Rothwell
2024-02-19  2:58 Stephen Rothwell
2024-02-19 12:14 ` Catalin Marinas
2024-02-19 15:22   ` Marc Zyngier
2024-02-19 15:35     ` Mark Rutland
2024-02-19 15:43     ` Ard Biesheuvel
2024-02-19 16:49     ` Catalin Marinas
2023-10-24  2:28 Stephen Rothwell
2023-10-24  6:49 ` Oliver Upton
2023-10-17  1:30 Stephen Rothwell
2023-10-17 11:13 ` Catalin Marinas
2023-10-18 23:02   ` Oliver Upton
2023-11-01  2:36 ` Stephen Rothwell
2023-06-15  2:45 Stephen Rothwell
2023-06-15  7:37 ` Oliver Upton
2023-06-15  8:32   ` Catalin Marinas
2023-06-15  2:22 Stephen Rothwell
2023-06-15  7:14 ` Catalin Marinas
2023-07-03  0:50 ` Stephen Rothwell
2023-06-06  1:49 Stephen Rothwell
2023-06-06  9:20 ` Catalin Marinas
2023-06-07  1:05 ` Stephen Rothwell
2023-06-07  5:33   ` Oliver Upton
2023-06-07  8:45     ` Catalin Marinas
2023-02-06  1:44 Stephen Rothwell
2023-02-06  4:21 ` Stephen Rothwell
2023-02-06  8:37 ` Marc Zyngier
2023-02-06  8:43   ` Marc Zyngier
2022-09-19  4:05 Stephen Rothwell
2022-09-19  9:04 ` Marc Zyngier
2022-09-23 10:26   ` Catalin Marinas
2022-05-04  4:35 Stephen Rothwell
2022-05-04  7:06 ` Marc Zyngier
2022-05-04  8:08   ` Catalin Marinas
2022-05-23  6:36 ` Stephen Rothwell
2021-08-19  4:05 Stephen Rothwell
2021-08-20  9:27 ` Catalin Marinas
2021-08-12  3:33 Stephen Rothwell
2021-06-23  5:58 Stephen Rothwell
2021-04-13  5:43 Stephen Rothwell
2021-04-13 11:21 ` Ard Biesheuvel
2021-01-27  5:24 Stephen Rothwell
2020-12-04  5:44 Stephen Rothwell
2020-12-04 11:12 ` Marc Zyngier
2020-12-04  5:17 Stephen Rothwell
2020-09-30  6:26 Stephen Rothwell
2020-05-29  7:00 Stephen Rothwell
2019-07-08  7:24 Stephen Rothwell
2018-10-04  4:22 Stephen Rothwell
2018-10-04  4:07 Stephen Rothwell
2018-07-23  4:46 Stephen Rothwell
2018-07-23 10:45 ` Marc Zyngier
2018-08-16  0:15 ` Stephen Rothwell
2018-08-17  8:32   ` Paolo Bonzini
2018-08-17  9:33     ` Marc Zyngier
2018-06-01  6:23 Stephen Rothwell
2018-06-01  8:23 ` Marc Zyngier
2018-06-01  6:13 Stephen Rothwell
2018-03-28  5:05 Stephen Rothwell
2018-03-29  5:16 ` Stephen Rothwell
2017-08-25  4:57 Stephen Rothwell
2017-08-25  8:11 ` Marc Zyngier
2017-08-25  8:44   ` Christoffer Dall
2016-02-29  5:18 Stephen Rothwell
2016-02-24  2:38 Stephen Rothwell
2016-02-22  2:33 Stephen Rothwell
2016-02-22  9:26 ` Catalin Marinas
2016-02-22  2:28 Stephen Rothwell
2016-02-22  9:24 ` Catalin Marinas
2016-02-12  2:26 Stephen Rothwell
2015-01-22  5:07 Stephen Rothwell
2015-01-22  8:51 ` Marc Zyngier
2015-01-22 10:29   ` Mark Rutland
2015-01-22 23:05     ` Stephen Rothwell
2015-01-23  1:36   ` Wei Huang
2015-01-23 11:53   ` Christoffer Dall
2015-01-22  5:06 Stephen Rothwell

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