linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
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 16/18] arm64: kexec: configure trans_pgd page table for kexec
Date: Thu, 7 May 2020 17:22:36 +0100	[thread overview]
Message-ID: <5ed92d16-123c-8b79-0fc1-4cefdee65d5d@arm.com> (raw)
In-Reply-To: <20200326032420.27220-17-pasha.tatashin@soleen.com>

Hi Pavel,

On 26/03/2020 03:24, Pavel Tatashin wrote:
> Configure a page table located in kexec-safe memory that has
> the following mappings:
> 
> 1. identity mapping for text of relocation function with executable
>    permission.
> 2. linear mappings for all source ranges
> 3. linear mappings for all destination ranges.

Its taken this long to work out your definition of linear here doesn't match the way the
rest of the arch code uses the term.

You are using the MMU to re-assemble the scattered kexec image in VA space, so that the
relocation code doesn't have to walk the list.

While its a cool trick, I don't think this is a good idea, it makes it much harder to
debug as we have a new definition for VA->PA, instead of re-using the kernels. We should
do the least surprising thing. The person debugging a problem's first assumptions should
be correct. Doing this means any debug information printed before kexec() is suddenly
useless for debugging a problem that occurs during relocation.

...

Let me hack together what I've been describing and we can discuss whether its simpler.
(most of next week is gone already though...)

(some Nits below)

> diff --git a/arch/arm64/include/asm/kexec.h b/arch/arm64/include/asm/kexec.h
> index 0f758fd51518..8f4332ac607a 100644
> --- a/arch/arm64/include/asm/kexec.h
> +++ b/arch/arm64/include/asm/kexec.h
> @@ -108,6 +108,12 @@ extern const unsigned long kexec_el2_vectors_offset;
>   * el2_vector	If present means that relocation routine will go to EL1
>   *		from EL2 to do the copy, and then back to EL2 to do the jump
>   *		to new world.
> + * trans_ttbr0	idmap for relocation function and its argument
> + * trans_ttbr1	linear map for source/destination addresses.
> + * trans_t0sz	t0sz for idmap page in trans_ttbr0

You should be able to load the TTBR0_EL1 (and corresponding TCR_EL1.T0SZ) before kicking
off the relocation code. There should be no need to pass it in to assembly.

For example, hibernate sets TTBR0_EL1 in create_safe_exec_page().


> + * src_addr	linear map for source pages.
> + * dst_addr	linear map for destination pages.
> + * copy_len	Number of bytes that need to be copied
>   */
>  struct kern_reloc_arg {
>  	phys_addr_t head;

> @@ -70,10 +71,90 @@ static void *kexec_page_alloc(void *arg)
>  	return page_address(page);
>  }
>  
> +/*
> + * Map source segments starting from src_va, and map destination
> + * segments starting from dst_va, and return size of copy in
> + * *copy_len argument.
> + * Relocation function essentially needs to do:
> + * memcpy(dst_va, src_va, copy_len);
> + */
> +static int map_segments(struct kimage *kimage, pgd_t *pgdp,
> +			struct trans_pgd_info *info,
> +			unsigned long src_va,
> +			unsigned long dst_va,
> +			unsigned long *copy_len)
> +{
> +	unsigned long *ptr = 0;
> +	unsigned long dest = 0;
> +	unsigned long len = 0;
> +	unsigned long entry, addr;
> +	int rc;
> +
> +	for (entry = kimage->head; !(entry & IND_DONE); entry = *ptr++) {
> +		addr = entry & PAGE_MASK;
> +
> +		switch (entry & IND_FLAGS) {
> +		case IND_DESTINATION:
> +			dest = addr;
> +			break;

So we hope to always find a destination first?


> +		case IND_INDIRECTION:
> +			ptr = __va(addr);
> +			if (rc)
> +				return rc;

Where does rc come from?

> +			break;

> +		case IND_SOURCE:
> +			rc = trans_pgd_map_page(info, pgdp, __va(addr),
> +						src_va, PAGE_KERNEL);
> +			if (rc)
> +				return rc;
> +			rc = trans_pgd_map_page(info, pgdp, __va(dest),
> +						dst_va, PAGE_KERNEL);
> +			if (rc)
> +				return rc;
> +			dest += PAGE_SIZE;
> +			src_va += PAGE_SIZE;
> +			dst_va += PAGE_SIZE;
> +			len += PAGE_SIZE;
> +		}
> +	}
> +	*copy_len = len;
> +
> +	return 0;
> +}
> +
> @@ -89,9 +170,18 @@ int machine_kexec_post_load(struct kimage *kimage)
>  		kern_reloc_arg->el2_vector = __pa(reloc_code)
>  						+ kexec_el2_vectors_offset;
>  	}
> +
> +	/*
> +	 * If relocation is not needed, we do not need to enable MMU in

Strictly you aren't enabling it, but disabling it _after_ the relocation.


> +	 * relocation routine, therefore do not create page tables for
> +	 * scenarios such as crash kernel
> +	 */
> +	if (!(kimage->head & IND_DONE))
> +		rc = mmu_relocate_setup(kimage, reloc_code, kern_reloc_arg);
> +
>  	kexec_image_info(kimage);
>  
> -	return 0;
> +	return rc;
>  }


Thanks,

James

  reply	other threads:[~2020-05-07 16:22 UTC|newest]

Thread overview: 45+ 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 ` [PATCH v9 01/18] arm64: kexec: make dtb_mem always enabled Pavel Tatashin
2020-04-29 17:00   ` James Morse
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-04-29 17:00   ` James Morse
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-04-29 17:01   ` James Morse
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-04-29 17:01   ` James Morse
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-04-29 17:01   ` James Morse
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 ` [PATCH v9 07/18] arm64: trans_pgd: hibernate: idmap the single page that holds the copy page routines Pavel Tatashin
2020-04-29 17:01   ` James Morse
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-04-29 17:01   ` James Morse
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-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-04-29 17:01   ` James Morse
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-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-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-05-07 16:22   ` James Morse
2021-01-23  2:49     ` Pavel Tatashin
2020-03-26  3:24 ` [PATCH v9 14/18] arm64: kexec: offset for " Pavel Tatashin
2020-05-07 16:22   ` James Morse
2020-03-26  3:24 ` [PATCH v9 15/18] arm64: kexec: kexec EL2 vectors Pavel Tatashin
2020-04-29 17:35   ` Marc Zyngier
2021-01-25 19:07     ` Pavel Tatashin
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-05-07 16:22   ` James Morse [this message]
2020-03-26  3:24 ` [PATCH v9 17/18] arm64: kexec: enable MMU during kexec relocation Pavel Tatashin
2020-03-26  3:24 ` [PATCH v9 18/18] arm64: kexec: remove head from relocation argument 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=5ed92d16-123c-8b79-0fc1-4cefdee65d5d@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 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).