linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Stephen Rothwell <sfr@canb.auug.org.au>
To: Christoffer Dall <cdall@cs.columbia.edu>,
	Marc Zyngier <maz@kernel.org>,
	Catalin Marinas <catalin.marinas@arm.com>,
	Will Deacon <will@kernel.org>
Cc: Ard Biesheuvel <ardb@kernel.org>,
	Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
	Linux Next Mailing List <linux-next@vger.kernel.org>,
	Quentin Perret <qperret@google.com>
Subject: linux-next: manual merge of the kvm-arm tree with the arm64 tree
Date: Tue, 13 Apr 2021 15:43:05 +1000	[thread overview]
Message-ID: <20210413154305.49442969@canb.auug.org.au> (raw)

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

             reply	other threads:[~2021-04-13  5:43 UTC|newest]

Thread overview: 83+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-04-13  5:43 Stephen Rothwell [this message]
2021-04-13 11:21 ` linux-next: manual merge of the kvm-arm tree with the arm64 tree Ard Biesheuvel
  -- strict thread matches above, loose matches on Subject: below --
2024-03-08  1:54 Stephen Rothwell
2024-03-08  6:25 ` Oliver Upton
2024-03-08 12:30   ` Catalin Marinas
2024-03-08  1:47 Stephen Rothwell
2024-02-20  2:21 Stephen Rothwell
2024-02-19  2:58 Stephen Rothwell
2024-02-19 12:14 ` Catalin Marinas
2024-02-19 15:22   ` Marc Zyngier
2024-02-19 15:35     ` Mark Rutland
2024-02-19 15:43     ` Ard Biesheuvel
2024-02-19 16:49     ` Catalin Marinas
2023-10-24  2:28 Stephen Rothwell
2023-10-24  6:49 ` Oliver Upton
2023-10-17  1:30 Stephen Rothwell
2023-10-17 11:13 ` Catalin Marinas
2023-10-18 23:02   ` Oliver Upton
2023-11-01  2:36 ` Stephen Rothwell
2023-06-15  2:45 Stephen Rothwell
2023-06-15  7:37 ` Oliver Upton
2023-06-15  8:32   ` Catalin Marinas
2023-06-15  2:22 Stephen Rothwell
2023-06-15  7:14 ` Catalin Marinas
2023-07-03  0:50 ` Stephen Rothwell
2023-06-06  1:49 Stephen Rothwell
2023-06-06  9:20 ` Catalin Marinas
2023-06-07  1:05 ` Stephen Rothwell
2023-06-07  5:33   ` Oliver Upton
2023-06-07  8:45     ` Catalin Marinas
2023-02-06  1:44 Stephen Rothwell
2023-02-06  4:21 ` Stephen Rothwell
2023-02-06  8:37 ` Marc Zyngier
2023-02-06  8:43   ` Marc Zyngier
2022-09-19  4:05 Stephen Rothwell
2022-09-19  9:04 ` Marc Zyngier
2022-09-23 10:26   ` Catalin Marinas
2022-05-04  4:35 Stephen Rothwell
2022-05-04  7:06 ` Marc Zyngier
2022-05-04  8:08   ` Catalin Marinas
2022-05-23  6:36 ` Stephen Rothwell
2021-08-19  4:05 Stephen Rothwell
2021-08-20  9:27 ` Catalin Marinas
2021-08-12  3:33 Stephen Rothwell
2021-06-23  5:58 Stephen Rothwell
2021-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

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20210413154305.49442969@canb.auug.org.au \
    --to=sfr@canb.auug.org.au \
    --cc=ardb@kernel.org \
    --cc=catalin.marinas@arm.com \
    --cc=cdall@cs.columbia.edu \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-next@vger.kernel.org \
    --cc=maz@kernel.org \
    --cc=qperret@google.com \
    --cc=will@kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).