From: Alexandru Elisei <alexandru.elisei@arm.com>
To: Nikos Nikoleris <nikos.nikoleris@arm.com>
Cc: pbonzini@redhat.com, thuth@redhat.com,
kvmarm@lists.cs.columbia.edu, kvm@vger.kernel.org,
andrew.jones@linux.dev
Subject: Re: [kvm-unit-tests RFC PATCH 09/19] arm/arm64: Zero secondary CPUs' stack
Date: Wed, 10 Aug 2022 10:42:56 +0100 [thread overview]
Message-ID: <YvN9oLwmCESQoFun@monolith.localdoman> (raw)
In-Reply-To: <38ec5559-7c2a-9820-724d-6a192ea83ecb@arm.com>
Hi Nikos,
On Tue, Aug 09, 2022 at 01:56:13PM +0100, Nikos Nikoleris wrote:
> On 09/08/2022 10:15, Alexandru Elisei wrote:
> > For the boot CPU, the entire stack is zeroed in the entry code. For the
> > secondaries, only struct thread_info, which lives at the bottom of the
> > stack, is zeroed in thread_info_init().
> >
>
> That's a good point.
>
> > Be consistent and zero the entire stack for the secondaries. This should
> > also improve reproducibility of the testsuite, as all the stacks now start
> > with the same contents, which is zero. And now that all the stacks are
> > zeroed in the entry code, there is no need to explicitely zero struct
> > thread_info in thread_info_init().
> >
>
> Wouldn't it make more sense to call memset(sp, 0, THREAD_SIZE); from
> thread_stack_alloc() instead and avoid doing this in assembly? Do we expect
I prefer to do the zero'ing in assembly because:
1. For consistency, which is one of the main reasons this patch exists.
2. I don't want to deal with all the cache maintenance that is required for
inter-CPU communication. Let's keep it simple.
> anyone to jump to secondary_entry without calling thread_stack_alloc()
> first?
It's impossible to jump to secondary_data.entry without allocating the
stack first, because it's impossible to run C code without a valid stack.
Thanks,
Alex
>
> Thanks,
>
> Nikos
>
> > Signed-off-by: Alexandru Elisei <alexandru.elisei@arm.com>
> > ---
> > arm/cstart.S | 6 ++++++
> > arm/cstart64.S | 3 +++
> > lib/arm/processor.c | 1 -
> > lib/arm64/processor.c | 1 -
> > 4 files changed, 9 insertions(+), 2 deletions(-)
> >
> > diff --git a/arm/cstart.S b/arm/cstart.S
> > index 39260e0fa470..39e70f40986a 100644
> > --- a/arm/cstart.S
> > +++ b/arm/cstart.S
> > @@ -151,7 +151,13 @@ secondary_entry:
> > */
> > ldr r1, =secondary_data
> > ldr r0, [r1]
> > + mov r2, r0
> > + lsr r2, #THREAD_SHIFT
> > + lsl r2, #THREAD_SHIFT
> > + add r3, r2, #THREAD_SIZE
> > + zero_range r2, r3, r4, r5
> > mov sp, r0
> > +
> > bl exceptions_init
> > bl enable_vfp
> > diff --git a/arm/cstart64.S b/arm/cstart64.S
> > index d62360cf3859..54773676d1d5 100644
> > --- a/arm/cstart64.S
> > +++ b/arm/cstart64.S
> > @@ -156,6 +156,9 @@ secondary_entry:
> > /* set the stack */
> > adrp x0, secondary_data
> > ldr x0, [x0, :lo12:secondary_data]
> > + and x1, x0, #THREAD_MASK
> > + add x2, x1, #THREAD_SIZE
> > + zero_range x1, x2
> > mov sp, x0
> > /* finish init in C code */
> > diff --git a/lib/arm/processor.c b/lib/arm/processor.c
> > index 9d5759686b73..ceff1c0a1bd2 100644
> > --- a/lib/arm/processor.c
> > +++ b/lib/arm/processor.c
> > @@ -117,7 +117,6 @@ void do_handle_exception(enum vector v, struct pt_regs *regs)
> > void thread_info_init(struct thread_info *ti, unsigned int flags)
> > {
> > - memset(ti, 0, sizeof(struct thread_info));
> > ti->cpu = mpidr_to_cpu(get_mpidr());
> > ti->flags = flags;
> > }
> > diff --git a/lib/arm64/processor.c b/lib/arm64/processor.c
> > index 831207c16587..268b2858f0be 100644
> > --- a/lib/arm64/processor.c
> > +++ b/lib/arm64/processor.c
> > @@ -232,7 +232,6 @@ void install_vector_handler(enum vector v, vector_fn fn)
> > static void __thread_info_init(struct thread_info *ti, unsigned int flags)
> > {
> > - memset(ti, 0, sizeof(struct thread_info));
> > ti->cpu = mpidr_to_cpu(get_mpidr());
> > ti->flags = flags;
> > }
_______________________________________________
kvmarm mailing list
kvmarm@lists.cs.columbia.edu
https://lists.cs.columbia.edu/mailman/listinfo/kvmarm
WARNING: multiple messages have this Message-ID (diff)
From: Alexandru Elisei <alexandru.elisei@arm.com>
To: Nikos Nikoleris <nikos.nikoleris@arm.com>
Cc: pbonzini@redhat.com, thuth@redhat.com, andrew.jones@linux.dev,
kvm@vger.kernel.org, kvmarm@lists.cs.columbia.edu
Subject: Re: [kvm-unit-tests RFC PATCH 09/19] arm/arm64: Zero secondary CPUs' stack
Date: Wed, 10 Aug 2022 10:42:56 +0100 [thread overview]
Message-ID: <YvN9oLwmCESQoFun@monolith.localdoman> (raw)
In-Reply-To: <38ec5559-7c2a-9820-724d-6a192ea83ecb@arm.com>
Hi Nikos,
On Tue, Aug 09, 2022 at 01:56:13PM +0100, Nikos Nikoleris wrote:
> On 09/08/2022 10:15, Alexandru Elisei wrote:
> > For the boot CPU, the entire stack is zeroed in the entry code. For the
> > secondaries, only struct thread_info, which lives at the bottom of the
> > stack, is zeroed in thread_info_init().
> >
>
> That's a good point.
>
> > Be consistent and zero the entire stack for the secondaries. This should
> > also improve reproducibility of the testsuite, as all the stacks now start
> > with the same contents, which is zero. And now that all the stacks are
> > zeroed in the entry code, there is no need to explicitely zero struct
> > thread_info in thread_info_init().
> >
>
> Wouldn't it make more sense to call memset(sp, 0, THREAD_SIZE); from
> thread_stack_alloc() instead and avoid doing this in assembly? Do we expect
I prefer to do the zero'ing in assembly because:
1. For consistency, which is one of the main reasons this patch exists.
2. I don't want to deal with all the cache maintenance that is required for
inter-CPU communication. Let's keep it simple.
> anyone to jump to secondary_entry without calling thread_stack_alloc()
> first?
It's impossible to jump to secondary_data.entry without allocating the
stack first, because it's impossible to run C code without a valid stack.
Thanks,
Alex
>
> Thanks,
>
> Nikos
>
> > Signed-off-by: Alexandru Elisei <alexandru.elisei@arm.com>
> > ---
> > arm/cstart.S | 6 ++++++
> > arm/cstart64.S | 3 +++
> > lib/arm/processor.c | 1 -
> > lib/arm64/processor.c | 1 -
> > 4 files changed, 9 insertions(+), 2 deletions(-)
> >
> > diff --git a/arm/cstart.S b/arm/cstart.S
> > index 39260e0fa470..39e70f40986a 100644
> > --- a/arm/cstart.S
> > +++ b/arm/cstart.S
> > @@ -151,7 +151,13 @@ secondary_entry:
> > */
> > ldr r1, =secondary_data
> > ldr r0, [r1]
> > + mov r2, r0
> > + lsr r2, #THREAD_SHIFT
> > + lsl r2, #THREAD_SHIFT
> > + add r3, r2, #THREAD_SIZE
> > + zero_range r2, r3, r4, r5
> > mov sp, r0
> > +
> > bl exceptions_init
> > bl enable_vfp
> > diff --git a/arm/cstart64.S b/arm/cstart64.S
> > index d62360cf3859..54773676d1d5 100644
> > --- a/arm/cstart64.S
> > +++ b/arm/cstart64.S
> > @@ -156,6 +156,9 @@ secondary_entry:
> > /* set the stack */
> > adrp x0, secondary_data
> > ldr x0, [x0, :lo12:secondary_data]
> > + and x1, x0, #THREAD_MASK
> > + add x2, x1, #THREAD_SIZE
> > + zero_range x1, x2
> > mov sp, x0
> > /* finish init in C code */
> > diff --git a/lib/arm/processor.c b/lib/arm/processor.c
> > index 9d5759686b73..ceff1c0a1bd2 100644
> > --- a/lib/arm/processor.c
> > +++ b/lib/arm/processor.c
> > @@ -117,7 +117,6 @@ void do_handle_exception(enum vector v, struct pt_regs *regs)
> > void thread_info_init(struct thread_info *ti, unsigned int flags)
> > {
> > - memset(ti, 0, sizeof(struct thread_info));
> > ti->cpu = mpidr_to_cpu(get_mpidr());
> > ti->flags = flags;
> > }
> > diff --git a/lib/arm64/processor.c b/lib/arm64/processor.c
> > index 831207c16587..268b2858f0be 100644
> > --- a/lib/arm64/processor.c
> > +++ b/lib/arm64/processor.c
> > @@ -232,7 +232,6 @@ void install_vector_handler(enum vector v, vector_fn fn)
> > static void __thread_info_init(struct thread_info *ti, unsigned int flags)
> > {
> > - memset(ti, 0, sizeof(struct thread_info));
> > ti->cpu = mpidr_to_cpu(get_mpidr());
> > ti->flags = flags;
> > }
next prev parent reply other threads:[~2022-08-10 9:42 UTC|newest]
Thread overview: 102+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-08-09 9:15 [kvm-unit-tests RFC PATCH 00/19] arm/arm64: Rework cache maintenance at boot Alexandru Elisei
2022-08-09 9:15 ` Alexandru Elisei
2022-08-09 9:15 ` [kvm-unit-tests RFC PATCH 01/19] Makefile: Define __ASSEMBLY__ for assembly files Alexandru Elisei
2022-08-09 9:15 ` Alexandru Elisei
2022-08-09 12:36 ` Nikos Nikoleris
2022-08-09 12:36 ` Nikos Nikoleris
2022-09-20 8:11 ` Andrew Jones
2022-09-20 8:11 ` Andrew Jones
2022-08-09 9:15 ` [kvm-unit-tests RFC PATCH 02/19] lib/alloc_phys: Initialize align_min Alexandru Elisei
2022-08-09 9:15 ` Alexandru Elisei
2022-09-20 8:20 ` Andrew Jones
2022-09-20 8:20 ` Andrew Jones
2022-08-09 9:15 ` [kvm-unit-tests RFC PATCH 03/19] lib/alloc_phys: Use phys_alloc_aligned_safe and rename it to memalign_early Alexandru Elisei
2022-08-09 9:15 ` Alexandru Elisei
2022-09-20 8:27 ` Andrew Jones
2022-09-20 8:27 ` Andrew Jones
2022-08-09 9:15 ` [kvm-unit-tests RFC PATCH 04/19] powerpc: Use the page allocator Alexandru Elisei
2022-08-09 9:15 ` Alexandru Elisei
2022-08-09 9:15 ` Alexandru Elisei
2022-08-09 9:15 ` [kvm-unit-tests RFC PATCH 05/19] lib/alloc_phys: Remove locking Alexandru Elisei
2022-08-09 9:15 ` Alexandru Elisei
2022-09-20 8:45 ` Andrew Jones
2022-09-20 8:45 ` Andrew Jones
2022-09-20 13:20 ` Alexandru Elisei
2022-09-20 13:20 ` Alexandru Elisei
2022-09-20 14:59 ` Andrew Jones
2022-09-20 14:59 ` Andrew Jones
2022-09-26 15:04 ` Alexandru Elisei
2022-09-26 15:04 ` Alexandru Elisei
2022-08-09 9:15 ` [kvm-unit-tests RFC PATCH 06/19] lib/alloc_phys: Remove allocation accounting Alexandru Elisei
2022-08-09 9:15 ` Alexandru Elisei
2022-09-20 8:40 ` Andrew Jones
2022-09-20 8:40 ` Andrew Jones
2022-09-20 13:19 ` Alexandru Elisei
2022-09-20 13:19 ` Alexandru Elisei
2022-08-09 9:15 ` [kvm-unit-tests RFC PATCH 07/19] arm/arm64: Mark the phys_end parameter as unused in setup_mmu() Alexandru Elisei
2022-08-09 9:15 ` Alexandru Elisei
2022-09-20 8:58 ` Andrew Jones
2022-09-20 8:58 ` Andrew Jones
2022-09-26 11:01 ` Alexandru Elisei
2022-09-26 11:01 ` Alexandru Elisei
2022-08-09 9:15 ` [kvm-unit-tests RFC PATCH 08/19] arm/arm64: Use pgd_alloc() to allocate mmu_idmap Alexandru Elisei
2022-08-09 9:15 ` Alexandru Elisei
2022-09-20 9:05 ` Andrew Jones
2022-09-20 9:05 ` Andrew Jones
2022-08-09 9:15 ` [kvm-unit-tests RFC PATCH 09/19] arm/arm64: Zero secondary CPUs' stack Alexandru Elisei
2022-08-09 9:15 ` Alexandru Elisei
2022-08-09 12:56 ` Nikos Nikoleris
2022-08-09 12:56 ` Nikos Nikoleris
2022-08-10 9:42 ` Alexandru Elisei [this message]
2022-08-10 9:42 ` Alexandru Elisei
2022-08-10 10:00 ` Nikos Nikoleris
2022-08-10 10:00 ` Nikos Nikoleris
2022-09-20 9:24 ` Andrew Jones
2022-09-20 9:24 ` Andrew Jones
2022-08-09 9:15 ` [kvm-unit-tests RFC PATCH 10/19] arm/arm64: Enable the MMU early Alexandru Elisei
2022-08-09 9:15 ` Alexandru Elisei
2022-08-09 9:15 ` [kvm-unit-tests RFC PATCH 11/19] arm/arm64: Map the UART when creating the translation tables Alexandru Elisei
2022-08-09 9:15 ` Alexandru Elisei
2022-08-09 9:15 ` [kvm-unit-tests RFC PATCH 12/19] arm/arm64: assembler.h: Replace size with end address for dcache_by_line_op Alexandru Elisei
2022-08-09 9:15 ` Alexandru Elisei
2022-08-09 13:01 ` Nikos Nikoleris
2022-08-09 13:01 ` Nikos Nikoleris
2022-09-20 9:37 ` Andrew Jones
2022-09-20 9:37 ` Andrew Jones
2022-08-09 9:15 ` [kvm-unit-tests RFC PATCH 13/19] arm: page.h: Add missing libcflat.h include Alexandru Elisei
2022-08-09 9:15 ` Alexandru Elisei
2022-09-20 9:39 ` Andrew Jones
2022-09-20 9:39 ` Andrew Jones
2022-09-26 11:02 ` Alexandru Elisei
2022-09-26 11:02 ` Alexandru Elisei
2022-08-09 9:15 ` [kvm-unit-tests RFC PATCH 14/19] arm/arm64: Add C functions for doing cache maintenance Alexandru Elisei
2022-08-09 9:15 ` Alexandru Elisei
2022-08-09 9:15 ` [kvm-unit-tests RFC PATCH 15/19] lib/alloc_phys: Add callback to perform " Alexandru Elisei
2022-08-09 9:15 ` Alexandru Elisei
2022-08-09 9:15 ` [kvm-unit-tests RFC PATCH 16/19] arm/arm64: Allocate secondaries' stack using the page allocator Alexandru Elisei
2022-08-09 9:15 ` Alexandru Elisei
2022-09-20 9:58 ` Andrew Jones
2022-09-20 9:58 ` Andrew Jones
2022-08-09 9:15 ` [kvm-unit-tests RFC PATCH 17/19] arm/arm64: Configure secondaries' stack before enabling the MMU Alexandru Elisei
2022-08-09 9:15 ` Alexandru Elisei
2022-08-09 9:15 ` [kvm-unit-tests RFC PATCH 18/19] arm/arm64: Perform dcache maintenance at boot Alexandru Elisei
2022-08-09 9:15 ` Alexandru Elisei
2022-08-09 9:15 ` [kvm-unit-tests RFC PATCH 19/19] arm/arm64: Rework the cache maintenance in asm_mmu_disable Alexandru Elisei
2022-08-09 9:15 ` Alexandru Elisei
2022-08-09 13:53 ` Nikos Nikoleris
2022-08-09 13:53 ` Nikos Nikoleris
2022-08-09 14:22 ` Alexandru Elisei
2022-08-09 14:22 ` Alexandru Elisei
2022-08-09 15:53 ` Nikos Nikoleris
2022-08-09 15:53 ` Nikos Nikoleris
2022-08-09 16:53 ` Alexandru Elisei
2022-08-09 16:53 ` Alexandru Elisei
2022-08-09 19:48 ` Nikos Nikoleris
2022-08-09 19:48 ` Nikos Nikoleris
2022-08-10 8:52 ` Alexandru Elisei
2022-08-10 8:52 ` Alexandru Elisei
2022-08-09 9:49 ` [kvm-unit-tests RFC PATCH 00/19] arm/arm64: Rework cache maintenance at boot Alexandru Elisei
2022-08-09 9:49 ` Alexandru Elisei
2023-11-05 10:16 ` Alexandru Elisei
2023-11-06 9:37 ` Shaoqin Huang
2023-11-07 9:01 ` Alexandru Elisei
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=YvN9oLwmCESQoFun@monolith.localdoman \
--to=alexandru.elisei@arm.com \
--cc=andrew.jones@linux.dev \
--cc=kvm@vger.kernel.org \
--cc=kvmarm@lists.cs.columbia.edu \
--cc=nikos.nikoleris@arm.com \
--cc=pbonzini@redhat.com \
--cc=thuth@redhat.com \
/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.