[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [PATCH v3 2/3] xen/ppc: Relocate kernel to physical address 0 on boot
- To: Shawn Anastasio <sanastasio@xxxxxxxxxxxxxxxxxxxxx>
- From: Jan Beulich <jbeulich@xxxxxxxx>
- Date: Mon, 14 Aug 2023 15:09:57 +0200
- Arc-authentication-results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=suse.com; dmarc=pass action=none header.from=suse.com; dkim=pass header.d=suse.com; arc=none
- Arc-message-signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=OhUGqhbsvQurwhVSpHDXzEe2AfP4y+OtWovnAEhmgEs=; b=TSBivBJUh7GcVXRP7Draw4ZJkxfKDrZ01Kq0VeFzxayfrcZ6HGy6W1COkz6sFZ6tQgf9cwvC0rrCLu/fFT+C00aIs0b338WmQ5CQty2KyFa7oBN2nY3v7mMf2t3qTorrrzRapemQdIHFfUdeCjLXc5NMs17rgqxEcN67SfqjWayfsS5GjxkOq9cQY2oT7uLxFmwrfC5Y0p7ZBFAMj/kkhMCsIHoKDPhvH/mGF2OGwIfl5m3nqWg08FfPUcCZ/X+VdQrK0BXQlfbUuaJXwu5L2aB/cqK3/xLnwbL5uBBQDR0TUo9qIJxQsQq4hIT/Y7qc11zOsTBKAJVXhtmOCFZ2EQ==
- Arc-seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=dbKQoP7wWMKIcmPcex34DwquSY5pprVW8CWjQjqFBMrTQ8xD6UOX+7JY9y8WjvRaSXHHsMrTP3FWAg5BtRFJ/VMstvvU7cAlDQXW1Hvwd8YAdaIgzGk6q2bL8z79Uso3r2qHI6mlOIFb5h9UvQ1AqeUKAm0n4WS0wFe8DKFc/7jYqKWQtJkqUgd7cDCVD2qwJSdoEVW+5makPc7WTTO9dddqvhZUKRoSLS+5Gpgpw6sJGFB6K5RcPHX89KFd3SkIQNWqe8NJ1oCDx0uN1y+BlvdJAiYG5b7G2Ph7D60NW9iJ4cWOwzoKXc6YIj/nwjzj60AfO0MuVzNDnhHdwF8C9g==
- Authentication-results: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=suse.com;
- Cc: Timothy Pearson <tpearson@xxxxxxxxxxxxxxxxxxxxx>, Andrew Cooper <andrew.cooper3@xxxxxxxxxx>, xen-devel@xxxxxxxxxxxxxxxxxxxx
- Delivery-date: Mon, 14 Aug 2023 13:10:10 +0000
- List-id: Xen developer discussion <xen-devel.lists.xenproject.org>
On 10.08.2023 00:48, Shawn Anastasio wrote:
> --- a/xen/arch/ppc/ppc64/head.S
> +++ b/xen/arch/ppc/ppc64/head.S
> @@ -17,6 +17,33 @@ ENTRY(start)
> addis %r2, %r12, .TOC.-1b@ha
> addi %r2, %r2, .TOC.-1b@l
>
> + /*
> + * Copy Xen to physical address zero and jump to XEN_VIRT_START
> + * (0xc000000000000000). This works because the hardware will ignore the
> top
> + * four address bits when the MMU is off.
> + */
> + LOAD_REG_ADDR(%r1, _start)
> + LOAD_IMM64(%r12, XEN_VIRT_START)
> +
> + /* If we're at the correct address, skip copy */
> + cmpld %r1, %r12
> + beq .L_correct_address
> +
> + /* Copy bytes until _end */
> + LOAD_REG_ADDR(%r11, _end)
> + addi %r1, %r1, -8
> + li %r13, -8
> +.L_copy_xen:
> + ldu %r10, 8(%r1)
> + stdu %r10, 8(%r13)
> + cmpld %r1, %r11
> + blt .L_copy_xen
> +
> + /* Jump to XEN_VIRT_START */
> + mtctr %r12
> + bctr
> +.L_correct_address:
Somewhat related to my earlier remark towards using %sp instead of
%r1: Are you intentionally fiddling with the stack pointer here,
corrupting any earlier stack that the boot loader might have set?
This ...
> /* set up the initial stack */
> LOAD_REG_ADDR(%r1, cpu0_boot_stack)
> li %r11, 0
... is where you actually switch stacks. Using the stack pointer
here is likely okay, albeit a bit unusual, the more that you have
ample registers available for use.
Jan
|
