All of lore.kernel.org
 help / color / mirror / Atom feed
From: Catalin Marinas <catalin.marinas@arm.com>
To: Qais Yousef <qais.yousef@arm.com>
Cc: Will Deacon <will@kernel.org>, Marc Zyngier <maz@kernel.org>,
	"Peter Zijlstra (Intel)" <peterz@infradead.org>,
	Morten Rasmussen <morten.rasmussen@arm.com>,
	Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
	Linus Torvalds <torvalds@linux-foundation.org>,
	James Morse <james.morse@arm.com>,
	linux-arm-kernel@lists.infradead.org, linux-arch@vger.kernel.org
Subject: Re: [RFC PATCH v2 2/4] arm64: Add support for asymmetric AArch32 EL0 configurations
Date: Wed, 21 Oct 2020 17:52:47 +0100	[thread overview]
Message-ID: <20201021165246.GH3976@gaia> (raw)
In-Reply-To: <20201021162121.bdiopxvzscbhzzpt@e107158-lin>

On Wed, Oct 21, 2020 at 05:21:21PM +0100, Qais Yousef wrote:
> On 10/21/20 16:39, Will Deacon wrote:
> > On Wed, Oct 21, 2020 at 11:46:09AM +0100, Qais Yousef wrote:
> > > When the CONFIG_ASYMMETRIC_AARCH32 option is enabled (EXPERT), the type
> > > of the ARM64_HAS_32BIT_EL0 capability becomes WEAK_LOCAL_CPU_FEATURE.
> > > The kernel will now return true for system_supports_32bit_el0() and
> > > checks 32-bit tasks are affined to AArch32 capable CPUs only in
> > > do_notify_resume(). If the affinity contains a non-capable AArch32 CPU,
> > > the tasks will get SIGKILLed. If the last CPU supporting 32-bit is
> > > offlined, the kernel will SIGKILL any scheduled 32-bit tasks (the
> > > alternative is to prevent offlining through a new .cpu_disable feature
> > > entry).
> > > 
> > > In addition to the relaxation of the ARM64_HAS_32BIT_EL0 capability,
> > > this patch factors out the 32-bit cpuinfo and features setting into
> > > separate functions: __cpuinfo_store_cpu_32bit(),
> > > init_cpu_32bit_features(). The cpuinfo of the booting CPU
> > > (boot_cpu_data) is now updated on the first 32-bit capable CPU even if
> > > it is a secondary one. The ID_AA64PFR0_EL0_64BIT_ONLY feature is relaxed
> > > to FTR_NONSTRICT and FTR_HIGHER_SAFE when the asymmetric AArch32 support
> > > is enabled. The compat_elf_hwcaps are only verified for the
> > > AArch32-capable CPUs to still allow hotplugging AArch64-only CPUs.
> > > 
> > > Make sure that KVM never sees the asymmetric 32bit system. Guest can
> > > still ignore ID registers and force run 32bit at EL0.
> > > 
> > > Co-developed-by: Qais Yousef <qais.yousef@arm.com>
> > > Signed-off-by: Catalin Marinas <catalin.marinas@arm.com>
> > > Signed-off-by: Qais Yousef <qais.yousef@arm.com>
> > 
> > [...]
> > 
> > > diff --git a/arch/arm64/include/asm/thread_info.h b/arch/arm64/include/asm/thread_info.h
> > > index 5e784e16ee89..312974ab2c85 100644
> > > --- a/arch/arm64/include/asm/thread_info.h
> > > +++ b/arch/arm64/include/asm/thread_info.h
> > > @@ -67,6 +67,7 @@ void arch_release_task_struct(struct task_struct *tsk);
> > >  #define TIF_FOREIGN_FPSTATE	3	/* CPU's FP state is not current's */
> > >  #define TIF_UPROBE		4	/* uprobe breakpoint or singlestep */
> > >  #define TIF_FSCHECK		5	/* Check FS is USER_DS on return */
> > > +#define TIF_CHECK_32BIT_AFFINITY 6	/* Check thread affinity for asymmetric AArch32 */
> > 
> > I've looked through the patch and I still can't figure out why this extra
> > flag is needed. We know if a CPU supports 32-bit EL0, and we know whether
> > or not a task is 32-bit. So why the extra flag? Is it just a hangover from
> > the old series?
> 
> It did evolve a bit organically.
> 
> AFAICS it helps as an optimization to avoid the checks unnecessarily. If it's
> not expensive to do the checks in the loop in do_notify_resume() we can omit
> it. We will still protect it with system_supports_asym_32bit_el0() so the check
> is done on these systems only.

Ah, I think I remember now. We didn't want ret_to_user (entry.S) to
always go the work_pending path if there was no context switch for a
32-bit task. With the AArch32 check in do_notify_resume(), it would mean
we add _TIF_32BIT to the _TIF_WORK_MASK.

However, we could add an asm alternative if AArch32 asym is detected to
always route TIF_32BIT tasks to work_pending.

-- 
Catalin

WARNING: multiple messages have this Message-ID (diff)
From: Catalin Marinas <catalin.marinas@arm.com>
To: Qais Yousef <qais.yousef@arm.com>
Cc: linux-arch@vger.kernel.org, Will Deacon <will@kernel.org>,
	"Peter Zijlstra \(Intel\)" <peterz@infradead.org>,
	Marc Zyngier <maz@kernel.org>, James Morse <james.morse@arm.com>,
	Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
	Linus Torvalds <torvalds@linux-foundation.org>,
	Morten Rasmussen <morten.rasmussen@arm.com>,
	linux-arm-kernel@lists.infradead.org
Subject: Re: [RFC PATCH v2 2/4] arm64: Add support for asymmetric AArch32 EL0 configurations
Date: Wed, 21 Oct 2020 17:52:47 +0100	[thread overview]
Message-ID: <20201021165246.GH3976@gaia> (raw)
In-Reply-To: <20201021162121.bdiopxvzscbhzzpt@e107158-lin>

On Wed, Oct 21, 2020 at 05:21:21PM +0100, Qais Yousef wrote:
> On 10/21/20 16:39, Will Deacon wrote:
> > On Wed, Oct 21, 2020 at 11:46:09AM +0100, Qais Yousef wrote:
> > > When the CONFIG_ASYMMETRIC_AARCH32 option is enabled (EXPERT), the type
> > > of the ARM64_HAS_32BIT_EL0 capability becomes WEAK_LOCAL_CPU_FEATURE.
> > > The kernel will now return true for system_supports_32bit_el0() and
> > > checks 32-bit tasks are affined to AArch32 capable CPUs only in
> > > do_notify_resume(). If the affinity contains a non-capable AArch32 CPU,
> > > the tasks will get SIGKILLed. If the last CPU supporting 32-bit is
> > > offlined, the kernel will SIGKILL any scheduled 32-bit tasks (the
> > > alternative is to prevent offlining through a new .cpu_disable feature
> > > entry).
> > > 
> > > In addition to the relaxation of the ARM64_HAS_32BIT_EL0 capability,
> > > this patch factors out the 32-bit cpuinfo and features setting into
> > > separate functions: __cpuinfo_store_cpu_32bit(),
> > > init_cpu_32bit_features(). The cpuinfo of the booting CPU
> > > (boot_cpu_data) is now updated on the first 32-bit capable CPU even if
> > > it is a secondary one. The ID_AA64PFR0_EL0_64BIT_ONLY feature is relaxed
> > > to FTR_NONSTRICT and FTR_HIGHER_SAFE when the asymmetric AArch32 support
> > > is enabled. The compat_elf_hwcaps are only verified for the
> > > AArch32-capable CPUs to still allow hotplugging AArch64-only CPUs.
> > > 
> > > Make sure that KVM never sees the asymmetric 32bit system. Guest can
> > > still ignore ID registers and force run 32bit at EL0.
> > > 
> > > Co-developed-by: Qais Yousef <qais.yousef@arm.com>
> > > Signed-off-by: Catalin Marinas <catalin.marinas@arm.com>
> > > Signed-off-by: Qais Yousef <qais.yousef@arm.com>
> > 
> > [...]
> > 
> > > diff --git a/arch/arm64/include/asm/thread_info.h b/arch/arm64/include/asm/thread_info.h
> > > index 5e784e16ee89..312974ab2c85 100644
> > > --- a/arch/arm64/include/asm/thread_info.h
> > > +++ b/arch/arm64/include/asm/thread_info.h
> > > @@ -67,6 +67,7 @@ void arch_release_task_struct(struct task_struct *tsk);
> > >  #define TIF_FOREIGN_FPSTATE	3	/* CPU's FP state is not current's */
> > >  #define TIF_UPROBE		4	/* uprobe breakpoint or singlestep */
> > >  #define TIF_FSCHECK		5	/* Check FS is USER_DS on return */
> > > +#define TIF_CHECK_32BIT_AFFINITY 6	/* Check thread affinity for asymmetric AArch32 */
> > 
> > I've looked through the patch and I still can't figure out why this extra
> > flag is needed. We know if a CPU supports 32-bit EL0, and we know whether
> > or not a task is 32-bit. So why the extra flag? Is it just a hangover from
> > the old series?
> 
> It did evolve a bit organically.
> 
> AFAICS it helps as an optimization to avoid the checks unnecessarily. If it's
> not expensive to do the checks in the loop in do_notify_resume() we can omit
> it. We will still protect it with system_supports_asym_32bit_el0() so the check
> is done on these systems only.

Ah, I think I remember now. We didn't want ret_to_user (entry.S) to
always go the work_pending path if there was no context switch for a
32-bit task. With the AArch32 check in do_notify_resume(), it would mean
we add _TIF_32BIT to the _TIF_WORK_MASK.

However, we could add an asm alternative if AArch32 asym is detected to
always route TIF_32BIT tasks to work_pending.

-- 
Catalin

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

  reply	other threads:[~2020-10-21 16:52 UTC|newest]

Thread overview: 114+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-10-21 10:46 [RFC PATCH v2 0/4] Add support for Asymmetric AArch32 systems Qais Yousef
2020-10-21 10:46 ` Qais Yousef
2020-10-21 10:46 ` [RFC PATCH v2 1/4] arm64: kvm: Handle " Qais Yousef
2020-10-21 10:46   ` Qais Yousef
2020-10-21 12:02   ` Marc Zyngier
2020-10-21 12:02     ` Marc Zyngier
2020-10-21 13:35     ` Qais Yousef
2020-10-21 13:35       ` Qais Yousef
2020-10-21 13:51       ` Marc Zyngier
2020-10-21 13:51         ` Marc Zyngier
2020-10-21 14:38         ` Qais Yousef
2020-10-21 14:38           ` Qais Yousef
2020-11-02 17:58         ` Qais Yousef
2020-11-02 17:58           ` Qais Yousef
2020-10-21 10:46 ` [RFC PATCH v2 2/4] arm64: Add support for asymmetric AArch32 EL0 configurations Qais Yousef
2020-10-21 10:46   ` Qais Yousef
2020-10-21 15:39   ` Will Deacon
2020-10-21 15:39     ` Will Deacon
2020-10-21 16:21     ` Qais Yousef
2020-10-21 16:21       ` Qais Yousef
2020-10-21 16:52       ` Catalin Marinas [this message]
2020-10-21 16:52         ` Catalin Marinas
2020-10-21 17:39         ` Will Deacon
2020-10-21 17:39           ` Will Deacon
2020-10-22  9:53           ` Catalin Marinas
2020-10-22  9:53             ` Catalin Marinas
2020-10-21 10:46 ` [RFC PATCH v2 3/4] arm64: export emulate_sys_reg() Qais Yousef
2020-10-21 10:46   ` Qais Yousef
2020-10-21 10:46 ` [RFC PATCH v2 4/4] arm64: Export id_aar64fpr0 via sysfs Qais Yousef
2020-10-21 10:46   ` Qais Yousef
2020-10-21 11:09   ` Marc Zyngier
2020-10-21 11:09     ` Marc Zyngier
2020-10-21 11:25     ` Greg Kroah-Hartman
2020-10-21 11:25       ` Greg Kroah-Hartman
2020-10-21 11:46       ` Marc Zyngier
2020-10-21 11:46         ` Marc Zyngier
2020-10-21 12:11         ` Greg Kroah-Hartman
2020-10-21 12:11           ` Greg Kroah-Hartman
2020-10-21 13:18         ` Qais Yousef
2020-10-21 13:18           ` Qais Yousef
2020-10-21 12:15     ` Catalin Marinas
2020-10-21 12:15       ` Catalin Marinas
2020-10-21 13:20       ` Qais Yousef
2020-10-21 13:20         ` Qais Yousef
2020-10-21 13:33       ` Morten Rasmussen
2020-10-21 13:33         ` Morten Rasmussen
2020-10-21 14:09         ` Catalin Marinas
2020-10-21 14:09           ` Catalin Marinas
2020-10-21 14:41           ` Morten Rasmussen
2020-10-21 14:41             ` Morten Rasmussen
2020-10-21 14:45           ` Will Deacon
2020-10-21 14:45             ` Will Deacon
2020-10-21 15:10             ` Catalin Marinas
2020-10-21 15:10               ` Catalin Marinas
2020-10-21 15:37               ` Will Deacon
2020-10-21 15:37                 ` Will Deacon
2020-10-21 16:18                 ` Catalin Marinas
2020-10-21 16:18                   ` Catalin Marinas
2020-10-21 17:19                   ` Will Deacon
2020-10-21 17:19                     ` Will Deacon
2020-10-22  9:55                     ` Morten Rasmussen
2020-10-22  9:55                       ` Morten Rasmussen
2020-10-21 14:31         ` Qais Yousef
2020-10-21 14:31           ` Qais Yousef
2020-10-22 10:16           ` Morten Rasmussen
2020-10-22 10:16             ` Morten Rasmussen
2020-10-22 10:48             ` Qais Yousef
2020-10-22 10:48               ` Qais Yousef
2020-10-21 14:41       ` Will Deacon
2020-10-21 14:41         ` Will Deacon
2020-10-21 15:03         ` Qais Yousef
2020-10-21 15:03           ` Qais Yousef
2020-10-21 15:23           ` Will Deacon
2020-10-21 15:23             ` Will Deacon
2020-10-21 16:07             ` Qais Yousef
2020-10-21 16:07               ` Qais Yousef
2020-10-21 17:23               ` Will Deacon
2020-10-21 17:23                 ` Will Deacon
2020-10-21 19:57                 ` Qais Yousef
2020-10-21 19:57                   ` Qais Yousef
2020-10-21 20:26                   ` Will Deacon
2020-10-21 20:26                     ` Will Deacon
2020-10-22  8:16                     ` Catalin Marinas
2020-10-22  8:16                       ` Catalin Marinas
2020-10-22  9:58                       ` Qais Yousef
2020-10-22  9:58                         ` Qais Yousef
2020-10-22 13:47         ` Qais Yousef
2020-10-22 13:47           ` Qais Yousef
2020-10-22 13:55           ` Greg Kroah-Hartman
2020-10-22 13:55             ` Greg Kroah-Hartman
2020-10-22 14:31             ` Catalin Marinas
2020-10-22 14:31               ` Catalin Marinas
2020-10-22 14:34               ` Qais Yousef
2020-10-22 14:34                 ` Qais Yousef
2020-10-26 19:02             ` Qais Yousef
2020-10-26 19:02               ` Qais Yousef
2020-10-26 19:08               ` Greg Kroah-Hartman
2020-10-26 19:08                 ` Greg Kroah-Hartman
2020-10-26 19:18                 ` Qais Yousef
2020-10-26 19:18                   ` Qais Yousef
2020-10-21 11:28   ` Greg Kroah-Hartman
2020-10-21 11:28     ` Greg Kroah-Hartman
2020-10-21 13:22     ` Qais Yousef
2020-10-21 13:22       ` Qais Yousef
2020-10-21 11:26 ` [RFC PATCH v2 0/4] Add support for Asymmetric AArch32 systems Greg Kroah-Hartman
2020-10-21 11:26   ` Greg Kroah-Hartman
2020-10-21 13:15   ` Qais Yousef
2020-10-21 13:15     ` Qais Yousef
2020-10-21 13:31     ` Greg Kroah-Hartman
2020-10-21 13:31       ` Greg Kroah-Hartman
2020-10-21 13:55       ` Qais Yousef
2020-10-21 13:55         ` Qais Yousef
2020-10-21 14:35       ` Catalin Marinas
2020-10-21 14:35         ` Catalin Marinas

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=20201021165246.GH3976@gaia \
    --to=catalin.marinas@arm.com \
    --cc=gregkh@linuxfoundation.org \
    --cc=james.morse@arm.com \
    --cc=linux-arch@vger.kernel.org \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=maz@kernel.org \
    --cc=morten.rasmussen@arm.com \
    --cc=peterz@infradead.org \
    --cc=qais.yousef@arm.com \
    --cc=torvalds@linux-foundation.org \
    --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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.