From: James Morse <james.morse@arm.com>
To: Pavel Tatashin <pasha.tatashin@soleen.com>
Cc: jmorris@namei.org, sashal@kernel.org, ebiederm@xmission.com,
kexec@lists.infradead.org, linux-kernel@vger.kernel.org,
corbet@lwn.net, catalin.marinas@arm.com, will@kernel.org,
linux-arm-kernel@lists.infradead.org, maz@kernel.org,
vladimir.murzin@arm.com, matthias.bgg@gmail.com,
bhsharma@redhat.com, linux-mm@kvack.org, mark.rutland@arm.com,
steve.capper@arm.com, rfontana@redhat.com, tglx@linutronix.de,
selindag@gmail.com
Subject: Re: [PATCH v9 13/18] arm64: kexec: add expandable argument to relocation function
Date: Thu, 7 May 2020 17:22:17 +0100 [thread overview]
Message-ID: <012e19d9-97d6-805a-bfec-8c6e7104f852@arm.com> (raw)
In-Reply-To: <20200326032420.27220-14-pasha.tatashin@soleen.com>
Hi Pavel,
On 26/03/2020 03:24, Pavel Tatashin wrote:
> Currently, kexec relocation function (arm64_relocate_new_kernel) accepts
> the following arguments:
>
> head: start of array that contains relocation information.
> entry: entry point for new kernel or purgatory.
> dtb_mem: first and only argument to entry.
> The number of arguments cannot be easily expended, because this
> function is also called from HVC_SOFT_RESTART, which preserves only
> three arguments. And, also arm64_relocate_new_kernel is written in
> assembly but called without stack, thus no place to move extra
> arguments to free registers.
>
> Soon, we will need to pass more arguments: once we enable MMU we
> will need to pass information about page tables.
> Another benefit of allowing this function to accept more arguments, is that
> kernel can actually accept up to 4 arguments (x0-x3), however currently
> only one is used, but if in the future we will need for more (for example,
> pass information about when previous kernel exited to have a precise
> measurement in time spent in purgatory), we won't be easilty do that
> if arm64_relocate_new_kernel can't accept more arguments.
This is a niche debug hack.
We really don't want an ABI with purgatory. I think the register values it gets were added
early for compatibility with kexec_file_load().
> So, add a new struct: kern_reloc_arg, and place it in kexec safe page (i.e
> memory that is not overwritten during relocation).
> Thus, make arm64_relocate_new_kernel to only take one argument, that
> contains all the needed information.
Do we really not have enough registers?
The PCS[0] gives you 8 arguments. In this patch you use 6.
If this is really about the hyp-stub abi, please state that.
> diff --git a/arch/arm64/kernel/machine_kexec.c b/arch/arm64/kernel/machine_kexec.c
> index cee3be586384..b1122eea627e 100644
> --- a/arch/arm64/kernel/machine_kexec.c
> +++ b/arch/arm64/kernel/machine_kexec.c
> @@ -59,13 +60,35 @@ void machine_kexec_cleanup(struct kimage *kimage)
> int machine_kexec_post_load(struct kimage *kimage)
> {
> void *reloc_code = page_to_virt(kimage->control_code_page);
> + struct kern_reloc_arg *kern_reloc_arg = kexec_page_alloc(kimage);
> +
> + if (!kern_reloc_arg)
> + return -ENOMEM;
>
> memcpy(reloc_code, arm64_relocate_new_kernel,
> arm64_relocate_new_kernel_size);
> kimage->arch.kern_reloc = __pa(reloc_code);
> + kimage->arch.kern_reloc_arg = __pa(kern_reloc_arg);
> + kern_reloc_arg->head = kimage->head;
> + kern_reloc_arg->entry_addr = kimage->start;
> + kern_reloc_arg->kern_arg0 = kimage->arch.dtb_mem;
These kern_reloc_arg values are written via the cacheable linear map.
They are read in arm64_relocate_new_kernel() where the MMU is disabled an all memory
access are non-cacheable.
To ensure you read the values you wrote, you must clean kern_reloc_arg to the PoC.
> kexec_image_info(kimage);
>
> return 0;Thanks,
James
[0]
https://developer.arm.com/docs/ihi0055/d/procedure-call-standard-for-the-arm-64-bit-architecture
WARNING: multiple messages have this Message-ID (diff)
From: James Morse <james.morse@arm.com>
To: Pavel Tatashin <pasha.tatashin@soleen.com>
Cc: sashal@kernel.org, mark.rutland@arm.com, vladimir.murzin@arm.com,
corbet@lwn.net, catalin.marinas@arm.com, bhsharma@redhat.com,
steve.capper@arm.com, kexec@lists.infradead.org,
linux-kernel@vger.kernel.org, jmorris@namei.org,
linux-mm@kvack.org, rfontana@redhat.com, ebiederm@xmission.com,
maz@kernel.org, matthias.bgg@gmail.com, tglx@linutronix.de,
will@kernel.org, selindag@gmail.com,
linux-arm-kernel@lists.infradead.org
Subject: Re: [PATCH v9 13/18] arm64: kexec: add expandable argument to relocation function
Date: Thu, 7 May 2020 17:22:17 +0100 [thread overview]
Message-ID: <012e19d9-97d6-805a-bfec-8c6e7104f852@arm.com> (raw)
In-Reply-To: <20200326032420.27220-14-pasha.tatashin@soleen.com>
Hi Pavel,
On 26/03/2020 03:24, Pavel Tatashin wrote:
> Currently, kexec relocation function (arm64_relocate_new_kernel) accepts
> the following arguments:
>
> head: start of array that contains relocation information.
> entry: entry point for new kernel or purgatory.
> dtb_mem: first and only argument to entry.
> The number of arguments cannot be easily expended, because this
> function is also called from HVC_SOFT_RESTART, which preserves only
> three arguments. And, also arm64_relocate_new_kernel is written in
> assembly but called without stack, thus no place to move extra
> arguments to free registers.
>
> Soon, we will need to pass more arguments: once we enable MMU we
> will need to pass information about page tables.
> Another benefit of allowing this function to accept more arguments, is that
> kernel can actually accept up to 4 arguments (x0-x3), however currently
> only one is used, but if in the future we will need for more (for example,
> pass information about when previous kernel exited to have a precise
> measurement in time spent in purgatory), we won't be easilty do that
> if arm64_relocate_new_kernel can't accept more arguments.
This is a niche debug hack.
We really don't want an ABI with purgatory. I think the register values it gets were added
early for compatibility with kexec_file_load().
> So, add a new struct: kern_reloc_arg, and place it in kexec safe page (i.e
> memory that is not overwritten during relocation).
> Thus, make arm64_relocate_new_kernel to only take one argument, that
> contains all the needed information.
Do we really not have enough registers?
The PCS[0] gives you 8 arguments. In this patch you use 6.
If this is really about the hyp-stub abi, please state that.
> diff --git a/arch/arm64/kernel/machine_kexec.c b/arch/arm64/kernel/machine_kexec.c
> index cee3be586384..b1122eea627e 100644
> --- a/arch/arm64/kernel/machine_kexec.c
> +++ b/arch/arm64/kernel/machine_kexec.c
> @@ -59,13 +60,35 @@ void machine_kexec_cleanup(struct kimage *kimage)
> int machine_kexec_post_load(struct kimage *kimage)
> {
> void *reloc_code = page_to_virt(kimage->control_code_page);
> + struct kern_reloc_arg *kern_reloc_arg = kexec_page_alloc(kimage);
> +
> + if (!kern_reloc_arg)
> + return -ENOMEM;
>
> memcpy(reloc_code, arm64_relocate_new_kernel,
> arm64_relocate_new_kernel_size);
> kimage->arch.kern_reloc = __pa(reloc_code);
> + kimage->arch.kern_reloc_arg = __pa(kern_reloc_arg);
> + kern_reloc_arg->head = kimage->head;
> + kern_reloc_arg->entry_addr = kimage->start;
> + kern_reloc_arg->kern_arg0 = kimage->arch.dtb_mem;
These kern_reloc_arg values are written via the cacheable linear map.
They are read in arm64_relocate_new_kernel() where the MMU is disabled an all memory
access are non-cacheable.
To ensure you read the values you wrote, you must clean kern_reloc_arg to the PoC.
> kexec_image_info(kimage);
>
> return 0;Thanks,
James
[0]
https://developer.arm.com/docs/ihi0055/d/procedure-call-standard-for-the-arm-64-bit-architecture
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
WARNING: multiple messages have this Message-ID (diff)
From: James Morse <james.morse@arm.com>
To: Pavel Tatashin <pasha.tatashin@soleen.com>
Cc: sashal@kernel.org, mark.rutland@arm.com, vladimir.murzin@arm.com,
corbet@lwn.net, catalin.marinas@arm.com, bhsharma@redhat.com,
steve.capper@arm.com, kexec@lists.infradead.org,
linux-kernel@vger.kernel.org, jmorris@namei.org,
linux-mm@kvack.org, rfontana@redhat.com, ebiederm@xmission.com,
maz@kernel.org, matthias.bgg@gmail.com, tglx@linutronix.de,
will@kernel.org, selindag@gmail.com,
linux-arm-kernel@lists.infradead.org
Subject: Re: [PATCH v9 13/18] arm64: kexec: add expandable argument to relocation function
Date: Thu, 7 May 2020 17:22:17 +0100 [thread overview]
Message-ID: <012e19d9-97d6-805a-bfec-8c6e7104f852@arm.com> (raw)
In-Reply-To: <20200326032420.27220-14-pasha.tatashin@soleen.com>
Hi Pavel,
On 26/03/2020 03:24, Pavel Tatashin wrote:
> Currently, kexec relocation function (arm64_relocate_new_kernel) accepts
> the following arguments:
>
> head: start of array that contains relocation information.
> entry: entry point for new kernel or purgatory.
> dtb_mem: first and only argument to entry.
> The number of arguments cannot be easily expended, because this
> function is also called from HVC_SOFT_RESTART, which preserves only
> three arguments. And, also arm64_relocate_new_kernel is written in
> assembly but called without stack, thus no place to move extra
> arguments to free registers.
>
> Soon, we will need to pass more arguments: once we enable MMU we
> will need to pass information about page tables.
> Another benefit of allowing this function to accept more arguments, is that
> kernel can actually accept up to 4 arguments (x0-x3), however currently
> only one is used, but if in the future we will need for more (for example,
> pass information about when previous kernel exited to have a precise
> measurement in time spent in purgatory), we won't be easilty do that
> if arm64_relocate_new_kernel can't accept more arguments.
This is a niche debug hack.
We really don't want an ABI with purgatory. I think the register values it gets were added
early for compatibility with kexec_file_load().
> So, add a new struct: kern_reloc_arg, and place it in kexec safe page (i.e
> memory that is not overwritten during relocation).
> Thus, make arm64_relocate_new_kernel to only take one argument, that
> contains all the needed information.
Do we really not have enough registers?
The PCS[0] gives you 8 arguments. In this patch you use 6.
If this is really about the hyp-stub abi, please state that.
> diff --git a/arch/arm64/kernel/machine_kexec.c b/arch/arm64/kernel/machine_kexec.c
> index cee3be586384..b1122eea627e 100644
> --- a/arch/arm64/kernel/machine_kexec.c
> +++ b/arch/arm64/kernel/machine_kexec.c
> @@ -59,13 +60,35 @@ void machine_kexec_cleanup(struct kimage *kimage)
> int machine_kexec_post_load(struct kimage *kimage)
> {
> void *reloc_code = page_to_virt(kimage->control_code_page);
> + struct kern_reloc_arg *kern_reloc_arg = kexec_page_alloc(kimage);
> +
> + if (!kern_reloc_arg)
> + return -ENOMEM;
>
> memcpy(reloc_code, arm64_relocate_new_kernel,
> arm64_relocate_new_kernel_size);
> kimage->arch.kern_reloc = __pa(reloc_code);
> + kimage->arch.kern_reloc_arg = __pa(kern_reloc_arg);
> + kern_reloc_arg->head = kimage->head;
> + kern_reloc_arg->entry_addr = kimage->start;
> + kern_reloc_arg->kern_arg0 = kimage->arch.dtb_mem;
These kern_reloc_arg values are written via the cacheable linear map.
They are read in arm64_relocate_new_kernel() where the MMU is disabled an all memory
access are non-cacheable.
To ensure you read the values you wrote, you must clean kern_reloc_arg to the PoC.
> kexec_image_info(kimage);
>
> return 0;Thanks,
James
[0]
https://developer.arm.com/docs/ihi0055/d/procedure-call-standard-for-the-arm-64-bit-architecture
_______________________________________________
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec
next prev parent reply other threads:[~2020-05-07 16:22 UTC|newest]
Thread overview: 126+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-03-26 3:24 [PATCH v9 00/18] arm64: MMU enabled kexec relocation Pavel Tatashin
2020-03-26 3:24 ` Pavel Tatashin
2020-03-26 3:24 ` [PATCH v9 01/18] arm64: kexec: make dtb_mem always enabled Pavel Tatashin
2020-03-26 3:24 ` Pavel Tatashin
2020-04-29 17:00 ` James Morse
2020-04-29 17:00 ` James Morse
2020-04-29 17:00 ` James Morse
2021-01-23 0:17 ` Pavel Tatashin
2021-01-23 0:17 ` Pavel Tatashin
2021-01-23 0:17 ` Pavel Tatashin
2021-01-23 0:17 ` Pavel Tatashin
2020-03-26 3:24 ` [PATCH v9 02/18] arm64: hibernate: move page handling function to new trans_pgd.c Pavel Tatashin
2020-03-26 3:24 ` Pavel Tatashin
2020-04-29 17:00 ` James Morse
2020-04-29 17:00 ` James Morse
2020-04-29 17:00 ` James Morse
2021-01-23 0:18 ` Pavel Tatashin
2021-01-23 0:18 ` Pavel Tatashin
2021-01-23 0:18 ` Pavel Tatashin
2021-01-23 0:18 ` Pavel Tatashin
2020-03-26 3:24 ` [PATCH v9 03/18] arm64: trans_pgd: make trans_pgd_map_page generic Pavel Tatashin
2020-03-26 3:24 ` Pavel Tatashin
2020-04-29 17:01 ` James Morse
2020-04-29 17:01 ` James Morse
2020-04-29 17:01 ` James Morse
2021-01-22 21:52 ` Pavel Tatashin
2021-01-22 21:52 ` Pavel Tatashin
2021-01-22 21:52 ` Pavel Tatashin
2021-01-22 21:52 ` Pavel Tatashin
2020-03-26 3:24 ` [PATCH v9 04/18] arm64: trans_pgd: pass allocator trans_pgd_create_copy Pavel Tatashin
2020-03-26 3:24 ` Pavel Tatashin
2020-04-29 17:01 ` James Morse
2020-04-29 17:01 ` James Morse
2020-04-29 17:01 ` James Morse
2021-01-23 0:20 ` Pavel Tatashin
2021-01-23 0:20 ` Pavel Tatashin
2021-01-23 0:20 ` Pavel Tatashin
2021-01-23 0:20 ` Pavel Tatashin
2020-03-26 3:24 ` [PATCH v9 05/18] arm64: trans_pgd: pass NULL instead of init_mm to *_populate functions Pavel Tatashin
2020-03-26 3:24 ` Pavel Tatashin
2020-04-29 17:01 ` James Morse
2020-04-29 17:01 ` James Morse
2020-04-29 17:01 ` James Morse
2021-01-23 0:22 ` Pavel Tatashin
2021-01-23 0:22 ` Pavel Tatashin
2021-01-23 0:22 ` Pavel Tatashin
2021-01-23 0:22 ` Pavel Tatashin
2020-03-26 3:24 ` [PATCH v9 06/18] arm64: mm: Always update TCR_EL1 from __cpu_set_tcr_t0sz() Pavel Tatashin
2020-03-26 3:24 ` Pavel Tatashin
2020-03-26 3:24 ` [PATCH v9 07/18] arm64: trans_pgd: hibernate: idmap the single page that holds the copy page routines Pavel Tatashin
2020-03-26 3:24 ` Pavel Tatashin
2020-04-29 17:01 ` James Morse
2020-04-29 17:01 ` James Morse
2020-04-29 17:01 ` James Morse
2021-01-23 0:35 ` Pavel Tatashin
2021-01-23 0:35 ` Pavel Tatashin
2021-01-23 0:35 ` Pavel Tatashin
2021-01-23 0:35 ` Pavel Tatashin
2020-03-26 3:24 ` [PATCH v9 08/18] arm64: kexec: move relocation function setup Pavel Tatashin
2020-03-26 3:24 ` Pavel Tatashin
2020-04-29 17:01 ` James Morse
2020-04-29 17:01 ` James Morse
2020-04-29 17:01 ` James Morse
2021-01-23 1:01 ` Pavel Tatashin
2021-01-23 1:01 ` Pavel Tatashin
2021-01-23 1:01 ` Pavel Tatashin
2021-01-23 1:01 ` Pavel Tatashin
2020-03-26 3:24 ` [PATCH v9 09/18] arm64: kexec: call kexec_image_info only once Pavel Tatashin
2020-03-26 3:24 ` Pavel Tatashin
2020-04-29 17:01 ` James Morse
2020-04-29 17:01 ` James Morse
2020-04-29 17:01 ` James Morse
2020-03-26 3:24 ` [PATCH v9 10/18] arm64: kexec: cpu_soft_restart change argument types Pavel Tatashin
2020-03-26 3:24 ` Pavel Tatashin
2020-04-29 17:01 ` James Morse
2020-04-29 17:01 ` James Morse
2020-04-29 17:01 ` James Morse
2021-01-23 1:14 ` Pavel Tatashin
2021-01-23 1:14 ` Pavel Tatashin
2021-01-23 1:14 ` Pavel Tatashin
2021-01-23 1:14 ` Pavel Tatashin
2020-03-26 3:24 ` [PATCH v9 11/18] arm64: kexec: arm64_relocate_new_kernel clean-ups Pavel Tatashin
2020-03-26 3:24 ` Pavel Tatashin
2020-05-07 16:22 ` James Morse
2020-05-07 16:22 ` James Morse
2020-05-07 16:22 ` James Morse
2020-03-26 3:24 ` [PATCH v9 12/18] arm64: kexec: arm64_relocate_new_kernel don't use x0 as temp Pavel Tatashin
2020-03-26 3:24 ` Pavel Tatashin
2020-05-07 16:22 ` James Morse
2020-05-07 16:22 ` James Morse
2020-05-07 16:22 ` James Morse
2020-03-26 3:24 ` [PATCH v9 13/18] arm64: kexec: add expandable argument to relocation function Pavel Tatashin
2020-03-26 3:24 ` Pavel Tatashin
2020-05-07 16:22 ` James Morse [this message]
2020-05-07 16:22 ` James Morse
2020-05-07 16:22 ` James Morse
2021-01-23 2:49 ` Pavel Tatashin
2021-01-23 2:49 ` Pavel Tatashin
2021-01-23 2:49 ` Pavel Tatashin
2021-01-23 2:49 ` Pavel Tatashin
2020-03-26 3:24 ` [PATCH v9 14/18] arm64: kexec: offset for " Pavel Tatashin
2020-03-26 3:24 ` Pavel Tatashin
2020-05-07 16:22 ` James Morse
2020-05-07 16:22 ` James Morse
2020-05-07 16:22 ` James Morse
2020-03-26 3:24 ` [PATCH v9 15/18] arm64: kexec: kexec EL2 vectors Pavel Tatashin
2020-03-26 3:24 ` Pavel Tatashin
2020-04-29 17:35 ` Marc Zyngier
2020-04-29 17:35 ` Marc Zyngier
2020-04-29 17:35 ` Marc Zyngier
2021-01-25 19:07 ` Pavel Tatashin
2021-01-25 19:07 ` Pavel Tatashin
2021-01-25 19:07 ` Pavel Tatashin
2021-01-25 19:07 ` Pavel Tatashin
2020-05-07 16:21 ` James Morse
2020-05-07 16:21 ` James Morse
2020-05-07 16:21 ` James Morse
2020-03-26 3:24 ` [PATCH v9 16/18] arm64: kexec: configure trans_pgd page table for kexec Pavel Tatashin
2020-03-26 3:24 ` Pavel Tatashin
2020-05-07 16:22 ` James Morse
2020-05-07 16:22 ` James Morse
2020-05-07 16:22 ` James Morse
2020-03-26 3:24 ` [PATCH v9 17/18] arm64: kexec: enable MMU during kexec relocation Pavel Tatashin
2020-03-26 3:24 ` Pavel Tatashin
2020-03-26 3:24 ` [PATCH v9 18/18] arm64: kexec: remove head from relocation argument Pavel Tatashin
2020-03-26 3:24 ` Pavel Tatashin
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=012e19d9-97d6-805a-bfec-8c6e7104f852@arm.com \
--to=james.morse@arm.com \
--cc=bhsharma@redhat.com \
--cc=catalin.marinas@arm.com \
--cc=corbet@lwn.net \
--cc=ebiederm@xmission.com \
--cc=jmorris@namei.org \
--cc=kexec@lists.infradead.org \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=mark.rutland@arm.com \
--cc=matthias.bgg@gmail.com \
--cc=maz@kernel.org \
--cc=pasha.tatashin@soleen.com \
--cc=rfontana@redhat.com \
--cc=sashal@kernel.org \
--cc=selindag@gmail.com \
--cc=steve.capper@arm.com \
--cc=tglx@linutronix.de \
--cc=vladimir.murzin@arm.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 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.