Linux-Next Archive on lore.kernel.org
 help / color / Atom feed
* 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; 40+ 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] 40+ messages in thread

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

On Tue, 13 Apr 2021 at 07:43, Stephen Rothwell <sfr@canb.auug.org.au> wrote:
>
> 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

Those patches are on a topic branch 'for-next/neon-softirqs-disabled'
in the arm64 tree, so probably best to just pull that into kvm-arm and
fix the conflicts there.

> 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

^ permalink raw reply	[flat|nested] 40+ 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; 40+ 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] 40+ messages in thread

* Re: 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, 0 replies; 40+ messages in thread
From: Marc Zyngier @ 2020-12-04 11:12 UTC (permalink / raw)
  To: Stephen Rothwell
  Cc: Christoffer Dall, Catalin Marinas, Will Deacon, David Brazdil,
	Linux Kernel Mailing List, Linux Next Mailing List, Mark Rutland

Hi Stephen,

On 2020-12-04 05:44, Stephen Rothwell wrote:
> 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.

Oops, my bad. I was planning to merge Mark's branch in before pushing 
the
whole thing out, and obviously forgot. Apologies for the mess.

I've now rebased David'd series on top of arm64/for-next/uaccess and 
pushed
the result out in the kvmarm/next branch.

Mark, David: I'd appreciate if you could have a look at the rebase 
result,
and let me know if you spot anything that would require fixing.

Thanks,

         M.
-- 
Jazz is not dead. It just smells funny...

^ permalink raw reply	[flat|nested] 40+ 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; 40+ 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] 40+ 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; 40+ 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] 40+ 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; 40+ 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] 40+ 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; 40+ 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] 40+ 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; 40+ 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] 40+ 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; 40+ 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] 40+ 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; 40+ 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] 40+ messages in thread

* Re: linux-next: manual merge of the kvm-arm tree with the arm64 tree
  2018-08-17  8:32   ` Paolo Bonzini
@ 2018-08-17  9:33     ` Marc Zyngier
  0 siblings, 0 replies; 40+ messages in thread
From: Marc Zyngier @ 2018-08-17  9:33 UTC (permalink / raw)
  To: Paolo Bonzini
  Cc: Stephen Rothwell, Christoffer Dall, Catalin Marinas, Will Deacon,
	Linux-Next Mailing List, Linux Kernel Mailing List,
	Suzuki K Poulose, Radim Krčmář,
	KVM

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

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

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

Thanks,

	M.

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

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

* Re: linux-next: manual merge of the kvm-arm tree with the arm64 tree
  2018-08-16  0:15 ` Stephen Rothwell
@ 2018-08-17  8:32   ` Paolo Bonzini
  2018-08-17  9:33     ` Marc Zyngier
  0 siblings, 1 reply; 40+ messages in thread
From: Paolo Bonzini @ 2018-08-17  8:32 UTC (permalink / raw)
  To: Stephen Rothwell, Christoffer Dall, Marc Zyngier
  Cc: Catalin Marinas, Will Deacon, Linux-Next Mailing List,
	Linux Kernel Mailing List, Suzuki K Poulose,
	Radim Krčmář,
	KVM

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

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

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

Thanks,

Paolo


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

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

* Re: 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
  2018-08-17  8:32   ` Paolo Bonzini
  1 sibling, 1 reply; 40+ messages in thread
From: Stephen Rothwell @ 2018-08-16  0:15 UTC (permalink / raw)
  To: Christoffer Dall, Marc Zyngier
  Cc: Catalin Marinas, Will Deacon, Linux-Next Mailing List,
	Linux Kernel Mailing List, Suzuki K Poulose, Paolo Bonzini,
	Radim Krčmář,
	KVM


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

Hi all,

On Mon, 23 Jul 2018 14:46:41 +1000 Stephen Rothwell <sfr@canb.auug.org.au> wrote:
>
> Today's linux-next merge of the kvm-arm tree got a conflict in:
> 
>   arch/arm64/include/asm/cpucaps.h
> 
> between commit:
> 
>   314d53d29798 ("arm64: Handle mismatched cache type")
> 
> from the arm64 tree and commit:
> 
>   e48d53a91f6e ("arm64: KVM: Add support for Stage-2 control of memory types and cacheability")
> 
> from the kvm-arm tree.
> 
> I fixed it up (see below) and can carry the fix as necessary. This
> is now fixed as far as linux-next is concerned, but any non trivial
> conflicts should be mentioned to your upstream maintainer when your tree
> is submitted for merging.  You may also want to consider cooperating
> with the maintainer of the conflicting tree to minimise any particularly
> complex conflicts.
> 
> -- 
> Cheers,
> Stephen Rothwell
> 
> diff --cc arch/arm64/include/asm/cpucaps.h
> index be3bf3d08916,ed84d6536830..000000000000
> --- a/arch/arm64/include/asm/cpucaps.h
> +++ b/arch/arm64/include/asm/cpucaps.h
> @@@ -49,8 -49,8 +49,9 @@@
>   #define ARM64_HAS_CACHE_DIC			28
>   #define ARM64_HW_DBM				29
>   #define ARM64_SSBD				30
>  -#define ARM64_HAS_STAGE2_FWB			31
>  +#define ARM64_MISMATCHED_CACHE_TYPE		31
> ++#define ARM64_HAS_STAGE2_FWB			32
>   
> --#define ARM64_NCAPS				32
> ++#define ARM64_NCAPS				33
>   
>   #endif /* __ASM_CPUCAPS_H */

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

-- 
Cheers,
Stephen Rothwell

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

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

* Re: 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
  1 sibling, 0 replies; 40+ messages in thread
From: Marc Zyngier @ 2018-07-23 10:45 UTC (permalink / raw)
  To: Stephen Rothwell, Christoffer Dall, Catalin Marinas, Will Deacon
  Cc: Linux-Next Mailing List, Linux Kernel Mailing List, Suzuki K Poulose

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

On 23/07/18 05:46, Stephen Rothwell wrote:
> 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.
> 

Looks good, thanks Stephen.

	M.
- -- 
Jazz is not dead. It just smells funny...
-----BEGIN PGP SIGNATURE-----

iQJJBAEBCAAzFiEEn9UcU+C1Yxj9lZw9I9DQutE9ekMFAltVscgVHG1hcmMuenlu
Z2llckBhcm0uY29tAAoJECPQ0LrRPXpDlcAP/1ahY/hghk5uJBrWdv13H0/wam85
OBB0xfaPU7f3HWIIZlyccMW+nY/mxxffdpZ4fGIiwMKfUNcshG0pjALNkvSmtgSx
UDehcHjHcdahqTG0SBFe0F8zISdCGgLEPgJ7Ow5RO+5RoNTQckNIPz92nUW5Hu3d
bTE41mMr+isFg6eYSVbBBHwuxN0PAVhQ9xDfJwEezfm5jcSTlg2nenRHbic6cf7o
utOXe27ZU2W278cwWGrk4iMmLg2EDJcPZ1nK15WI4GVL25sQGBX8MYScjiXImaBX
eF8aJtfd8xJ3LWH4ENgD0EEnt7dKGBTidZIZA86g1+LmZH+zA4/1AEWpidvsExPe
zH/b3N3Al8oLPMOJjxJEcFB2yAeTiyMJ+fRc9+6X/Tv0Pxj0FeyqrJrIDCLz8I0Y
fy4VL3nuHCyKtgFGWAM6hznM1scCm4JAwq3kE0Pe2sxHjClRPb1TjQ1IdALtL4tI
iSdth16dSBKluaMeVCBugOG+hfX11REUChkpMaX4X73ISOY87w1u40l1aqE3UBr3
XOOHW8bZ3TkDCrqtWxw4Cgb4fgTzJMbmINwoj77Hc57NdsV9WWTeS0T7lRdRFvbs
ohmMekjvc/3HjkiI1X+vKVFQdLdUtpAoo/j6MLAsx8F4hluneZS0bACM2oO6moVD
qRjj85emuDsA0a2R
=pFup
-----END PGP SIGNATURE-----

^ permalink raw reply	[flat|nested] 40+ 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; 40+ 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] 40+ messages in thread

* Re: 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, 0 replies; 40+ messages in thread
From: Marc Zyngier @ 2018-06-01  8:23 UTC (permalink / raw)
  To: Stephen Rothwell, Christoffer Dall, Catalin Marinas, Will Deacon
  Cc: Linux-Next Mailing List, Linux Kernel Mailing List, Dave Martin

Hi Stephen,

On 01/06/18 07:23, Stephen Rothwell wrote:
> 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.
> 

All three resolutions look correct to me.

Thanks,

	M.
-- 
Jazz is not dead. It just smells funny...

^ permalink raw reply	[flat|nested] 40+ 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; 40+ 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] 40+ 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; 40+ 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] 40+ messages in thread

* Re: 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, 0 replies; 40+ messages in thread
From: Stephen Rothwell @ 2018-03-29  5:16 UTC (permalink / raw)
  To: Catalin Marinas, Will Deacon, Paolo Bonzini,
	Radim Krčmář,
	KVM
  Cc: Christoffer Dall, Marc Zyngier, Linux-Next Mailing List,
	Linux Kernel Mailing List, Suzuki K Poulose


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

Hi all,

On Wed, 28 Mar 2018 16:05:41 +1100 Stephen Rothwell <sfr@canb.auug.org.au> wrote:
>
> Today's linux-next merge of the kvm-arm tree got a conflict in:
> 
>   arch/arm64/kernel/cpufeature.c
> 
> between commits:
> 
>   143ba05d867a ("arm64: capabilities: Prepare for fine grained capabilities")
>   12eb369125ab ("arm64: cpufeature: Avoid warnings due to unused symbols")
> 
> from the arm64 tree and commit:
> 
>   a1efdff442ec ("arm64: cpufeatures: Drop the ARM64_HYP_OFFSET_LOW feature flag")
> 
> from the kvm-arm tree.
> 
> I fixed it up (see below) and can carry the fix as necessary. This
> is now fixed as far as linux-next is concerned, but any non trivial
> conflicts should be mentioned to your upstream maintainer when your tree
> is submitted for merging.  You may also want to consider cooperating
> with the maintainer of the conflicting tree to minimise any particularly
> complex conflicts.
> 
> -- 
> Cheers,
> Stephen Rothwell
> 
> diff --cc arch/arm64/kernel/cpufeature.c
> index 96b15d7b10a8,5b25d56bccfd..000000000000
> --- a/arch/arm64/kernel/cpufeature.c
> +++ b/arch/arm64/kernel/cpufeature.c
> @@@ -838,19 -826,11 +838,6 @@@ static bool has_no_hw_prefetch(const st
>   		MIDR_CPU_VAR_REV(1, MIDR_REVISION_MASK));
>   }
>   
> - static bool hyp_offset_low(const struct arm64_cpu_capabilities *entry,
> - 			   int __unused)
>  -static bool runs_at_el2(const struct arm64_cpu_capabilities *entry, int __unused)
> --{
> - 	phys_addr_t idmap_addr = __pa_symbol(__hyp_idmap_text_start);
> - 
> - 	/*
> - 	 * Activate the lower HYP offset only if:
> - 	 * - the idmap doesn't clash with it,
> - 	 * - the kernel is not running at EL2.
> - 	 */
> - 	return idmap_addr > GENMASK(VA_BITS - 2, 0) && !is_kernel_in_hyp_mode();
>  -	return is_kernel_in_hyp_mode();
> --}
> --
>   static bool has_no_fpsimd(const struct arm64_cpu_capabilities *entry, int __unused)
>   {
>   	u64 pfr0 = read_sanitised_ftr_reg(SYS_ID_AA64PFR0_EL1);

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

-- 
Cheers,
Stephen Rothwell

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

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

* Re: 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, 0 replies; 40+ messages in thread
From: Will Deacon @ 2018-03-28 11:53 UTC (permalink / raw)
  To: Stephen Rothwell
  Cc: Christoffer Dall, Marc Zyngier, Catalin Marinas,
	Linux-Next Mailing List, Linux Kernel Mailing List,
	Shanker Donthineni, Dave Martin, Suzuki K Poulose

Hi Stephen,

On Wed, Mar 28, 2018 at 04:00:34PM +1100, Stephen Rothwell wrote:
> 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.

This is a really grotty conflict, so Marc and I have decided to revert
f9f5dc19509b ("arm64: KVM: Use SMCCC_ARCH_WORKAROUND_1 for Falkor BP hardening")
from kvm-arm for now. There's a little hack necessary to keep things
building after that, but we can clean that up at -rc1.

Shanker -- I'm still aiming to get your patch into 4.17, either during the
second half of the merge window or at -rc1.

Cheers,

Will

^ permalink raw reply	[flat|nested] 40+ 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; 40+ 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] 40+ messages in thread

* 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; 40+ 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] 40+ messages in thread

* Re: linux-next: manual merge of the kvm-arm tree with the arm64 tree
  2017-08-25  8:11 ` Marc Zyngier
@ 2017-08-25  8:44   ` Christoffer Dall
  0 siblings, 0 replies; 40+ messages in thread
From: Christoffer Dall @ 2017-08-25  8:44 UTC (permalink / raw)
  To: Marc Zyngier
  Cc: Stephen Rothwell, Catalin Marinas, Linux-Next Mailing List,
	Linux Kernel Mailing List, James Morse, Julien Thierry

On Fri, Aug 25, 2017 at 10:11 AM, Marc Zyngier <marc.zyngier@arm.com> wrote:
> Hi Stephen,
>
> On Fri, Aug 25 2017 at  2:57:21 pm BST, Stephen Rothwell <sfr@canb.auug.org.au> wrote:
>> 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.
>
> Thanks for that, result looking good.
>
> Christoffer: I think we could simply drop the hunk touching esr.h from
> James' patch. After all, even if nothing is using it, this bit still
> exists in the ESR register, and there is little gain in dropping its
> definition. This would solve the conflict nicely...
>

Yes, I have updated the branch accordingly and added my signed-off-by as well.

Thanks,
-Christoffer

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

* Re: 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
  2017-08-25  8:44   ` Christoffer Dall
  0 siblings, 1 reply; 40+ messages in thread
From: Marc Zyngier @ 2017-08-25  8:11 UTC (permalink / raw)
  To: Stephen Rothwell, Christoffer Dall
  Cc: Catalin Marinas, Linux-Next Mailing List,
	Linux Kernel Mailing List, James Morse, Julien Thierry

Hi Stephen,

On Fri, Aug 25 2017 at  2:57:21 pm BST, Stephen Rothwell <sfr@canb.auug.org.au> wrote:
> 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.

Thanks for that, result looking good.

Christoffer: I think we could simply drop the hunk touching esr.h from
James' patch. After all, even if nothing is using it, this bit still
exists in the ESR register, and there is little gain in dropping its
definition. This would solve the conflict nicely...

Thanks,

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

^ permalink raw reply	[flat|nested] 40+ 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; 40+ 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] 40+ 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; 40+ 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] 40+ 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; 40+ 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] 40+ messages in thread

* Re: 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, 0 replies; 40+ messages in thread
From: Catalin Marinas @ 2016-02-22  9:26 UTC (permalink / raw)
  To: Stephen Rothwell
  Cc: Christoffer Dall, Marc Zyngier, linux-next, linux-kernel, Ard Biesheuvel

On Mon, Feb 22, 2016 at 01:33:22PM +1100, Stephen Rothwell wrote:
> 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).

This looks correct as well. Thanks.

-- 
Catalin

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

* Re: 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, 0 replies; 40+ messages in thread
From: Catalin Marinas @ 2016-02-22  9:24 UTC (permalink / raw)
  To: Stephen Rothwell
  Cc: Christoffer Dall, Marc Zyngier, linux-next, linux-kernel,
	Will Deacon, James Morse

Hi Stephen,

On Mon, Feb 22, 2016 at 01:28:29PM +1100, Stephen Rothwell wrote:
> 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).

The fix-up looks correct indeed. Thanks.

-- 
Catalin

^ permalink raw reply	[flat|nested] 40+ 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; 40+ 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] 40+ 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; 40+ 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] 40+ 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; 40+ 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] 40+ messages in thread

* Re: linux-next: manual merge of the kvm-arm tree with the arm64 tree
  2015-01-22  8:51 ` Marc Zyngier
  2015-01-22 10:29   ` Mark Rutland
  2015-01-23  1:36   ` Wei Huang
@ 2015-01-23 11:53   ` Christoffer Dall
  2 siblings, 0 replies; 40+ messages in thread
From: Christoffer Dall @ 2015-01-23 11:53 UTC (permalink / raw)
  To: Marc Zyngier
  Cc: Stephen Rothwell, linux-next, linux-kernel, Catalin Marinas,
	Mark Rutland, Wei Huang

On Thu, Jan 22, 2015 at 08:51:54AM +0000, Marc Zyngier wrote:
> On Thu, Jan 22 2015 at  5:07:04 am GMT, Stephen Rothwell <sfr@canb.auug.org.au> wrote:
> 
> Hi Stephen,
> 
> > 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).
> 
> Thanks for dealing with this. I think the following patch should be
> applied on top of your resolution, making the new macro part of the
> asm/esr.h file.
> 
> Mark, Wei: does it match your expectations?
> 
> Thanks,
> 
> 	M.
> 
> diff --git a/arch/arm64/include/asm/esr.h b/arch/arm64/include/asm/esr.h
> index 6216709..92bbae3 100644
> --- a/arch/arm64/include/asm/esr.h
> +++ b/arch/arm64/include/asm/esr.h
> @@ -96,6 +96,7 @@
>  #define ESR_ELx_COND_SHIFT	(20)
>  #define ESR_ELx_COND_MASK	(UL(0xF) << ESR_ELx_COND_SHIFT)
>  #define ESR_ELx_WFx_ISS_WFE	(UL(1) << 0)
> +#define ESR_ELx_xVC_IMM_MASK	((1UL << 16) - 1)
>  
>  #ifndef __ASSEMBLY__
>  #include <asm/types.h>
> diff --git a/arch/arm64/include/asm/kvm_arm.h b/arch/arm64/include/asm/kvm_arm.h
> index 53fbc1e..94674eb 100644
> --- a/arch/arm64/include/asm/kvm_arm.h
> +++ b/arch/arm64/include/asm/kvm_arm.h
> @@ -192,6 +192,4 @@
>  /* Hyp Prefetch Fault Address Register (HPFAR/HDFAR) */
>  #define HPFAR_MASK	(~UL(0xf))
>  
> -#define ESR_EL2_HVC_IMM_MASK	((1UL << 16) - 1)
> -
>  #endif /* __ARM64_KVM_ARM_H__ */
> diff --git a/arch/arm64/include/asm/kvm_emulate.h b/arch/arm64/include/asm/kvm_emulate.h
> index b861ff6..bbc17cd 100644
> --- a/arch/arm64/include/asm/kvm_emulate.h
> +++ b/arch/arm64/include/asm/kvm_emulate.h
> @@ -133,7 +133,7 @@ static inline phys_addr_t kvm_vcpu_get_fault_ipa(const struct kvm_vcpu *vcpu)
>  
>  static inline u32 kvm_vcpu_hvc_get_imm(const struct kvm_vcpu *vcpu)
>  {
> -	return kvm_vcpu_get_hsr(vcpu) & ESR_EL2_HVC_IMM_MASK;
> +	return kvm_vcpu_get_hsr(vcpu) & ESR_ELx_xVC_IMM_MASK;
>  }
>  
>  static inline bool kvm_vcpu_dabt_isvalid(const struct kvm_vcpu *vcpu)
> 

This looks good to me too, I'll sync with Paolo on how to get this
upstream.

-Christoffer

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

* Re: linux-next: manual merge of the kvm-arm tree with the arm64 tree
  2015-01-22  8:51 ` Marc Zyngier
  2015-01-22 10:29   ` Mark Rutland
@ 2015-01-23  1:36   ` Wei Huang
  2015-01-23 11:53   ` Christoffer Dall
  2 siblings, 0 replies; 40+ messages in thread
From: Wei Huang @ 2015-01-23  1:36 UTC (permalink / raw)
  To: Marc Zyngier, Stephen Rothwell
  Cc: Christoffer Dall, linux-next, linux-kernel, Catalin Marinas,
	Mark Rutland

On 01/22/2015 02:51 AM, Marc Zyngier wrote:
> On Thu, Jan 22 2015 at  5:07:04 am GMT, Stephen Rothwell <sfr@canb.auug.org.au> wrote:
> 
> Hi Stephen,
> 
>> 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).
> 
> Thanks for dealing with this. I think the following patch should be
> applied on top of your resolution, making the new macro part of the
> asm/esr.h file.
> 
> Mark, Wei: does it match your expectations?
Looks good to me. Thanks for handling this issue.

-Wei

> 
> Thanks,
> 
> 	M.
> 
> diff --git a/arch/arm64/include/asm/esr.h b/arch/arm64/include/asm/esr.h
> index 6216709..92bbae3 100644
> --- a/arch/arm64/include/asm/esr.h
> +++ b/arch/arm64/include/asm/esr.h
> @@ -96,6 +96,7 @@
>  #define ESR_ELx_COND_SHIFT	(20)
>  #define ESR_ELx_COND_MASK	(UL(0xF) << ESR_ELx_COND_SHIFT)
>  #define ESR_ELx_WFx_ISS_WFE	(UL(1) << 0)
> +#define ESR_ELx_xVC_IMM_MASK	((1UL << 16) - 1)
>  
>  #ifndef __ASSEMBLY__
>  #include <asm/types.h>
> diff --git a/arch/arm64/include/asm/kvm_arm.h b/arch/arm64/include/asm/kvm_arm.h
> index 53fbc1e..94674eb 100644
> --- a/arch/arm64/include/asm/kvm_arm.h
> +++ b/arch/arm64/include/asm/kvm_arm.h
> @@ -192,6 +192,4 @@
>  /* Hyp Prefetch Fault Address Register (HPFAR/HDFAR) */
>  #define HPFAR_MASK	(~UL(0xf))
>  
> -#define ESR_EL2_HVC_IMM_MASK	((1UL << 16) - 1)
> -
>  #endif /* __ARM64_KVM_ARM_H__ */
> diff --git a/arch/arm64/include/asm/kvm_emulate.h b/arch/arm64/include/asm/kvm_emulate.h
> index b861ff6..bbc17cd 100644
> --- a/arch/arm64/include/asm/kvm_emulate.h
> +++ b/arch/arm64/include/asm/kvm_emulate.h
> @@ -133,7 +133,7 @@ static inline phys_addr_t kvm_vcpu_get_fault_ipa(const struct kvm_vcpu *vcpu)
>  
>  static inline u32 kvm_vcpu_hvc_get_imm(const struct kvm_vcpu *vcpu)
>  {
> -	return kvm_vcpu_get_hsr(vcpu) & ESR_EL2_HVC_IMM_MASK;
> +	return kvm_vcpu_get_hsr(vcpu) & ESR_ELx_xVC_IMM_MASK;
>  }
>  
>  static inline bool kvm_vcpu_dabt_isvalid(const struct kvm_vcpu *vcpu)
> 

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

* Re: linux-next: manual merge of the kvm-arm tree with the arm64 tree
  2015-01-22 10:29   ` Mark Rutland
@ 2015-01-22 23:05     ` Stephen Rothwell
  0 siblings, 0 replies; 40+ messages in thread
From: Stephen Rothwell @ 2015-01-22 23:05 UTC (permalink / raw)
  To: Mark Rutland
  Cc: Marc Zyngier, Christoffer Dall, linux-next, linux-kernel,
	Catalin Marinas, Wei Huang


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

Hi Mark,

On Thu, 22 Jan 2015 10:29:20 +0000 Mark Rutland <mark.rutland@arm.com> wrote:
>
> On Thu, Jan 22, 2015 at 08:51:54AM +0000, Marc Zyngier wrote:
> > On Thu, Jan 22 2015 at  5:07:04 am GMT, Stephen Rothwell <sfr@canb.auug.org.au> wrote:
> > 
> > > Today's linux-next merge of the kvm-arm tree got a conflict in
> > > arch/arm64/include/asm/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).
> > 
> > Thanks for dealing with this. I think the following patch should be
> > applied on top of your resolution, making the new macro part of the
> > asm/esr.h file.
> > 
> > Mark, Wei: does it match your expectations?
> 
> The below patch looks fine to me.
> 
> I suspected we mighh see something like this, so I kept my
> arm64/common-esr-macros branch [1] stable. Catalin merged this into the
> arm64 for-next/core branch.
> 
> I guess the easiest way to solve the conflict would be if the kvm-arm
> tree also merged that and fixed the fallout there?

Yes, that would be a good resolution.  In the mean time, I will apply
the merge fix patch to my tree (I will remove it when the above
resolution is done).
-- 
Cheers,
Stephen Rothwell                    sfr@canb.auug.org.au

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

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

* Re: linux-next: manual merge of the kvm-arm tree with the arm64 tree
  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
  2 siblings, 1 reply; 40+ messages in thread
From: Mark Rutland @ 2015-01-22 10:29 UTC (permalink / raw)
  To: Marc Zyngier
  Cc: Stephen Rothwell, Christoffer Dall, linux-next, linux-kernel,
	Catalin Marinas, Wei Huang

On Thu, Jan 22, 2015 at 08:51:54AM +0000, Marc Zyngier wrote:
> On Thu, Jan 22 2015 at  5:07:04 am GMT, Stephen Rothwell <sfr@canb.auug.org.au> wrote:
> 
> Hi Stephen,
> 
> > 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).
> 
> Thanks for dealing with this. I think the following patch should be
> applied on top of your resolution, making the new macro part of the
> asm/esr.h file.
> 
> Mark, Wei: does it match your expectations?

The below patch looks fine to me.

I suspected we mighh see something like this, so I kept my
arm64/common-esr-macros branch [1] stable. Catalin merged this into the
arm64 for-next/core branch.

I guess the easiest way to solve the conflict would be if the kvm-arm
tree also merged that and fixed the fallout there?

Thanks,
Mark.

[1] git://git.kernel.org/pub/scm/linux/kernel/git/mark/linux.git arm64/common-esr-macros

> 
> Thanks,
> 
> 	M.
> 
> diff --git a/arch/arm64/include/asm/esr.h b/arch/arm64/include/asm/esr.h
> index 6216709..92bbae3 100644
> --- a/arch/arm64/include/asm/esr.h
> +++ b/arch/arm64/include/asm/esr.h
> @@ -96,6 +96,7 @@
>  #define ESR_ELx_COND_SHIFT	(20)
>  #define ESR_ELx_COND_MASK	(UL(0xF) << ESR_ELx_COND_SHIFT)
>  #define ESR_ELx_WFx_ISS_WFE	(UL(1) << 0)
> +#define ESR_ELx_xVC_IMM_MASK	((1UL << 16) - 1)
>  
>  #ifndef __ASSEMBLY__
>  #include <asm/types.h>
> diff --git a/arch/arm64/include/asm/kvm_arm.h b/arch/arm64/include/asm/kvm_arm.h
> index 53fbc1e..94674eb 100644
> --- a/arch/arm64/include/asm/kvm_arm.h
> +++ b/arch/arm64/include/asm/kvm_arm.h
> @@ -192,6 +192,4 @@
>  /* Hyp Prefetch Fault Address Register (HPFAR/HDFAR) */
>  #define HPFAR_MASK	(~UL(0xf))
>  
> -#define ESR_EL2_HVC_IMM_MASK	((1UL << 16) - 1)
> -
>  #endif /* __ARM64_KVM_ARM_H__ */
> diff --git a/arch/arm64/include/asm/kvm_emulate.h b/arch/arm64/include/asm/kvm_emulate.h
> index b861ff6..bbc17cd 100644
> --- a/arch/arm64/include/asm/kvm_emulate.h
> +++ b/arch/arm64/include/asm/kvm_emulate.h
> @@ -133,7 +133,7 @@ static inline phys_addr_t kvm_vcpu_get_fault_ipa(const struct kvm_vcpu *vcpu)
>  
>  static inline u32 kvm_vcpu_hvc_get_imm(const struct kvm_vcpu *vcpu)
>  {
> -	return kvm_vcpu_get_hsr(vcpu) & ESR_EL2_HVC_IMM_MASK;
> +	return kvm_vcpu_get_hsr(vcpu) & ESR_ELx_xVC_IMM_MASK;
>  }
>  
>  static inline bool kvm_vcpu_dabt_isvalid(const struct kvm_vcpu *vcpu)
> 
> -- 
> Jazz is not dead. It just smells funny.
> 

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

* Re: 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
  2015-01-22 10:29   ` Mark Rutland
                     ` (2 more replies)
  0 siblings, 3 replies; 40+ messages in thread
From: Marc Zyngier @ 2015-01-22  8:51 UTC (permalink / raw)
  To: Stephen Rothwell
  Cc: Christoffer Dall, linux-next, linux-kernel, Catalin Marinas,
	Mark Rutland, Wei Huang

On Thu, Jan 22 2015 at  5:07:04 am GMT, Stephen Rothwell <sfr@canb.auug.org.au> wrote:

Hi Stephen,

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

Thanks for dealing with this. I think the following patch should be
applied on top of your resolution, making the new macro part of the
asm/esr.h file.

Mark, Wei: does it match your expectations?

Thanks,

	M.

diff --git a/arch/arm64/include/asm/esr.h b/arch/arm64/include/asm/esr.h
index 6216709..92bbae3 100644
--- a/arch/arm64/include/asm/esr.h
+++ b/arch/arm64/include/asm/esr.h
@@ -96,6 +96,7 @@
 #define ESR_ELx_COND_SHIFT	(20)
 #define ESR_ELx_COND_MASK	(UL(0xF) << ESR_ELx_COND_SHIFT)
 #define ESR_ELx_WFx_ISS_WFE	(UL(1) << 0)
+#define ESR_ELx_xVC_IMM_MASK	((1UL << 16) - 1)
 
 #ifndef __ASSEMBLY__
 #include <asm/types.h>
diff --git a/arch/arm64/include/asm/kvm_arm.h b/arch/arm64/include/asm/kvm_arm.h
index 53fbc1e..94674eb 100644
--- a/arch/arm64/include/asm/kvm_arm.h
+++ b/arch/arm64/include/asm/kvm_arm.h
@@ -192,6 +192,4 @@
 /* Hyp Prefetch Fault Address Register (HPFAR/HDFAR) */
 #define HPFAR_MASK	(~UL(0xf))
 
-#define ESR_EL2_HVC_IMM_MASK	((1UL << 16) - 1)
-
 #endif /* __ARM64_KVM_ARM_H__ */
diff --git a/arch/arm64/include/asm/kvm_emulate.h b/arch/arm64/include/asm/kvm_emulate.h
index b861ff6..bbc17cd 100644
--- a/arch/arm64/include/asm/kvm_emulate.h
+++ b/arch/arm64/include/asm/kvm_emulate.h
@@ -133,7 +133,7 @@ static inline phys_addr_t kvm_vcpu_get_fault_ipa(const struct kvm_vcpu *vcpu)
 
 static inline u32 kvm_vcpu_hvc_get_imm(const struct kvm_vcpu *vcpu)
 {
-	return kvm_vcpu_get_hsr(vcpu) & ESR_EL2_HVC_IMM_MASK;
+	return kvm_vcpu_get_hsr(vcpu) & ESR_ELx_xVC_IMM_MASK;
 }
 
 static inline bool kvm_vcpu_dabt_isvalid(const struct kvm_vcpu *vcpu)

-- 
Jazz is not dead. It just smells funny.

^ permalink raw reply	[flat|nested] 40+ 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; 40+ 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] 40+ 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; 40+ 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] 40+ messages in thread

end of thread, back to index

Thread overview: 40+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2021-04-13  5:43 linux-next: manual merge of the kvm-arm tree with the arm64 tree Stephen Rothwell
2021-04-13 11:21 ` Ard Biesheuvel
  -- strict thread matches above, loose matches on Subject: below --
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
2018-03-28  5:00 Stephen Rothwell
2018-03-28 11:53 ` Will Deacon
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

Linux-Next Archive on lore.kernel.org

Archives are clonable:
	git clone --mirror https://lore.kernel.org/linux-next/0 linux-next/git/0.git

	# If you have public-inbox 1.1+ installed, you may
	# initialize and index your mirror using the following commands:
	public-inbox-init -V2 linux-next linux-next/ https://lore.kernel.org/linux-next \
		linux-next@vger.kernel.org
	public-inbox-index linux-next

Example config snippet for mirrors

Newsgroup available over NNTP:
	nntp://nntp.lore.kernel.org/org.kernel.vger.linux-next


AGPL code for this site: git clone https://public-inbox.org/public-inbox.git