All of lore.kernel.org
 help / color / mirror / Atom feed
From: Alan Kao <alankao@andestech.com>
To: Christoph Hellwig <hch@lst.de>
Cc: linux-kernel@vger.kernel.org,
	Damien Le Moal <damien.lemoal@wdc.com>,
	Palmer Dabbelt <palmer@sifive.com>,
	linux-riscv@lists.infradead.org,
	Paul Walmsley <paul.walmsley@sifive.com>
Subject: Re: [PATCH 13/15] riscv: clear the instruction cache and all registers when booting
Date: Wed, 14 Aug 2019 09:00:14 +0800	[thread overview]
Message-ID: <20190814010013.GA18655@andestech.com> (raw)
In-Reply-To: <20190813154747.24256-14-hch@lst.de>

Hi Christoph,

On Tue, Aug 13, 2019 at 05:47:45PM +0200, Christoph Hellwig wrote:
> When we get booted we want a clear slate without any leaks from previous
> supervisors or the firmware.  Flush the instruction cache and then clear
> all registers to known good values.  This is really important for the
> upcoming nommu support that runs on M-mode, but can't really harm when
> running in S-mode either.  

Sure.

> +#ifdef CONFIG_FPU

But it doesn't really mean that the running system has an FPU given CONFIG_FPU
enabled.  Normally the existence of an FPU is checked in riscv_fill_hwcap by
searching device tree, where the code looks like


bool has_fpu = false; // this one is global
...
#ifdef CONFIG_FPU
        if (elf_hwcap & (COMPAT_HWCAP_ISA_F | COMPAT_HWCAP_ISA_D))
                has_fpu = true;
#endif


Or does CONFIG_FPU have a more intuitive meaning when CONFIG_M_MODE is enabled?

> +	csrr	t0, CSR_MISA
> +	andi	t0, t0, (COMPAT_HWCAP_ISA_F | COMPAT_HWCAP_ISA_D)
> +	bnez	t0, .Lreset_regs_done
> +
> +	li	t1, SR_FS
> +	csrs	CSR_XSTATUS, t1
> +	fmv.s.x	f0, zero
> +	fmv.s.x	f1, zero
> +	fmv.s.x	f2, zero
> +	fmv.s.x	f3, zero
> +	fmv.s.x	f4, zero
> +	fmv.s.x	f5, zero
> +	fmv.s.x	f6, zero
> +	fmv.s.x	f7, zero
> +	fmv.s.x	f8, zero
> +	fmv.s.x	f9, zero
> +	fmv.s.x	f10, zero
> +	fmv.s.x	f11, zero
> +	fmv.s.x	f12, zero
> +	fmv.s.x	f13, zero
> +	fmv.s.x	f14, zero
> +	fmv.s.x	f15, zero
> +	fmv.s.x	f16, zero
> +	fmv.s.x	f17, zero
> +	fmv.s.x	f18, zero
> +	fmv.s.x	f19, zero
> +	fmv.s.x	f20, zero
> +	fmv.s.x	f21, zero
> +	fmv.s.x	f22, zero
> +	fmv.s.x	f23, zero
> +	fmv.s.x	f24, zero
> +	fmv.s.x	f25, zero
> +	fmv.s.x	f26, zero
> +	fmv.s.x	f27, zero
> +	fmv.s.x	f28, zero
> +	fmv.s.x	f29, zero
> +	fmv.s.x	f30, zero
> +	fmv.s.x	f31, zero
> +	csrw	fcsr, 0
> +	/* note that the caller must clear SR_FS */
> +#endif /* CONFIG_FPU */

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

WARNING: multiple messages have this Message-ID (diff)
From: Alan Kao <alankao@andestech.com>
To: Christoph Hellwig <hch@lst.de>
Cc: Palmer Dabbelt <palmer@sifive.com>,
	Paul Walmsley <paul.walmsley@sifive.com>,
	Damien Le Moal <damien.lemoal@wdc.com>,
	<linux-riscv@lists.infradead.org>, <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH 13/15] riscv: clear the instruction cache and all registers when booting
Date: Wed, 14 Aug 2019 09:00:14 +0800	[thread overview]
Message-ID: <20190814010013.GA18655@andestech.com> (raw)
In-Reply-To: <20190813154747.24256-14-hch@lst.de>

Hi Christoph,

On Tue, Aug 13, 2019 at 05:47:45PM +0200, Christoph Hellwig wrote:
> When we get booted we want a clear slate without any leaks from previous
> supervisors or the firmware.  Flush the instruction cache and then clear
> all registers to known good values.  This is really important for the
> upcoming nommu support that runs on M-mode, but can't really harm when
> running in S-mode either.  

Sure.

> +#ifdef CONFIG_FPU

But it doesn't really mean that the running system has an FPU given CONFIG_FPU
enabled.  Normally the existence of an FPU is checked in riscv_fill_hwcap by
searching device tree, where the code looks like


bool has_fpu = false; // this one is global
...
#ifdef CONFIG_FPU
        if (elf_hwcap & (COMPAT_HWCAP_ISA_F | COMPAT_HWCAP_ISA_D))
                has_fpu = true;
#endif


Or does CONFIG_FPU have a more intuitive meaning when CONFIG_M_MODE is enabled?

> +	csrr	t0, CSR_MISA
> +	andi	t0, t0, (COMPAT_HWCAP_ISA_F | COMPAT_HWCAP_ISA_D)
> +	bnez	t0, .Lreset_regs_done
> +
> +	li	t1, SR_FS
> +	csrs	CSR_XSTATUS, t1
> +	fmv.s.x	f0, zero
> +	fmv.s.x	f1, zero
> +	fmv.s.x	f2, zero
> +	fmv.s.x	f3, zero
> +	fmv.s.x	f4, zero
> +	fmv.s.x	f5, zero
> +	fmv.s.x	f6, zero
> +	fmv.s.x	f7, zero
> +	fmv.s.x	f8, zero
> +	fmv.s.x	f9, zero
> +	fmv.s.x	f10, zero
> +	fmv.s.x	f11, zero
> +	fmv.s.x	f12, zero
> +	fmv.s.x	f13, zero
> +	fmv.s.x	f14, zero
> +	fmv.s.x	f15, zero
> +	fmv.s.x	f16, zero
> +	fmv.s.x	f17, zero
> +	fmv.s.x	f18, zero
> +	fmv.s.x	f19, zero
> +	fmv.s.x	f20, zero
> +	fmv.s.x	f21, zero
> +	fmv.s.x	f22, zero
> +	fmv.s.x	f23, zero
> +	fmv.s.x	f24, zero
> +	fmv.s.x	f25, zero
> +	fmv.s.x	f26, zero
> +	fmv.s.x	f27, zero
> +	fmv.s.x	f28, zero
> +	fmv.s.x	f29, zero
> +	fmv.s.x	f30, zero
> +	fmv.s.x	f31, zero
> +	csrw	fcsr, 0
> +	/* note that the caller must clear SR_FS */
> +#endif /* CONFIG_FPU */

  reply	other threads:[~2019-08-14  1:00 UTC|newest]

Thread overview: 90+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-08-13 15:47 RISC-V nommu support v3 Christoph Hellwig
2019-08-13 15:47 ` Christoph Hellwig
2019-08-13 15:47 ` [PATCH 01/15] irqchip/sifive-plic: set max threshold for ignored handlers Christoph Hellwig
2019-08-13 15:47   ` Christoph Hellwig
2019-08-13 17:44   ` Paul Walmsley
2019-08-13 17:44     ` Paul Walmsley
2019-08-14  9:06     ` Marc Zyngier
2019-08-14  9:06       ` Marc Zyngier
2019-08-13 15:47 ` [PATCH 02/15] riscv: use CSR_SATP instead of the legacy sptbr name in switch_mm Christoph Hellwig
2019-08-13 15:47   ` Christoph Hellwig
2019-08-13 16:36   ` Paul Walmsley
2019-08-13 16:36     ` Paul Walmsley
2019-08-13 16:42     ` Christoph Hellwig
2019-08-13 16:42       ` Christoph Hellwig
2019-08-13 16:51       ` Paul Walmsley
2019-08-13 16:51         ` Paul Walmsley
2019-08-13 19:44   ` Paul Walmsley
2019-08-13 19:44     ` Paul Walmsley
2019-08-13 15:47 ` [PATCH 03/15] riscv: refactor the IPI code Christoph Hellwig
2019-08-13 15:47   ` Christoph Hellwig
2019-08-14  4:41   ` Paul Walmsley
2019-08-14  4:41     ` Paul Walmsley
2019-08-19 10:18     ` Christoph Hellwig
2019-08-19 10:18       ` Christoph Hellwig
2019-09-01  8:03     ` Christoph Hellwig
2019-09-01  8:03       ` Christoph Hellwig
2019-08-13 15:47 ` [PATCH 04/15] riscv: abstract out CSR names for supervisor vs machine mode Christoph Hellwig
2019-08-13 15:47   ` Christoph Hellwig
2019-08-13 15:47 ` [PATCH 05/15] riscv: improve the default power off implementation Christoph Hellwig
2019-08-13 15:47   ` Christoph Hellwig
2019-08-13 15:47 ` [PATCH 06/15] riscv: provide a flat entry loader Christoph Hellwig
2019-08-13 15:47   ` Christoph Hellwig
2019-08-13 15:47 ` [PATCH 07/15] riscv: read the hart ID from mhartid on boot Christoph Hellwig
2019-08-13 15:47   ` Christoph Hellwig
2019-08-13 15:47 ` [PATCH 08/15] riscv: provide native clint access for M-mode Christoph Hellwig
2019-08-13 15:47   ` Christoph Hellwig
2019-08-13 16:29   ` Mark Rutland
2019-08-13 16:29     ` Mark Rutland
2019-08-19 10:16     ` Christoph Hellwig
2019-08-19 10:16       ` Christoph Hellwig
2019-08-27 23:37       ` Palmer Dabbelt
2019-08-27 23:37         ` Palmer Dabbelt
2019-08-28  6:11         ` Christoph Hellwig
2019-08-28  6:11           ` Christoph Hellwig
2019-09-03 18:48           ` Palmer Dabbelt
2019-09-03 18:48             ` Palmer Dabbelt
2019-09-04  2:05             ` Alan Kao
2019-09-04  2:05               ` Alan Kao
2019-08-21  0:24   ` Atish Patra
2019-08-21  0:24     ` Atish Patra
2019-08-21  0:42     ` hch
2019-08-21  0:42       ` hch
2019-08-13 15:47 ` [PATCH 09/15] riscv: implement remote sfence.i natively " Christoph Hellwig
2019-08-13 15:47   ` Christoph Hellwig
2019-08-20 21:04   ` Atish Patra
2019-08-20 21:04     ` Atish Patra
2019-08-13 15:47 ` [PATCH 10/15] riscv: poison SBI calls " Christoph Hellwig
2019-08-13 15:47   ` Christoph Hellwig
2019-08-20 21:05   ` Atish Patra
2019-08-20 21:05     ` Atish Patra
2019-08-13 15:47 ` [PATCH 11/15] riscv: don't allow selecting SBI-based drivers " Christoph Hellwig
2019-08-13 15:47   ` Christoph Hellwig
2019-08-13 15:47 ` [PATCH 12/15] riscv: use the correct interrupt levels " Christoph Hellwig
2019-08-13 15:47   ` Christoph Hellwig
2019-08-13 15:47 ` [PATCH 13/15] riscv: clear the instruction cache and all registers when booting Christoph Hellwig
2019-08-13 15:47   ` Christoph Hellwig
2019-08-14  1:00   ` Alan Kao [this message]
2019-08-14  1:00     ` Alan Kao
2019-08-14  1:07     ` Alan Kao
2019-08-14  1:07       ` Alan Kao
2019-08-14  4:35     ` Christoph Hellwig
2019-08-14  4:35       ` Christoph Hellwig
2019-08-13 15:47 ` [PATCH 14/15] riscv: add nommu support Christoph Hellwig
2019-08-13 15:47   ` Christoph Hellwig
2019-08-13 15:47 ` [PATCH 15/15] riscv: disable the EFI PECOFF header for M-mode Christoph Hellwig
2019-08-13 15:47   ` Christoph Hellwig
2019-08-20 21:07   ` Atish Patra
2019-08-20 21:07     ` Atish Patra
2019-08-21  4:14   ` Troy Benjegerdes
2019-08-21  4:14     ` Troy Benjegerdes
2019-08-21  7:12     ` Christoph Hellwig
2019-08-21  7:12       ` Christoph Hellwig
2019-08-21 17:31     ` Atish Patra
2019-08-21 17:31       ` Atish Patra
2019-08-21 17:54       ` Troy Benjegerdes
2019-08-21 17:54         ` Troy Benjegerdes
2019-08-21 23:02         ` Anup Patel
2019-08-21 23:02           ` Anup Patel
2019-08-21 23:32           ` Troy Benjegerdes
2019-08-21 23:32             ` Troy Benjegerdes

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=20190814010013.GA18655@andestech.com \
    --to=alankao@andestech.com \
    --cc=damien.lemoal@wdc.com \
    --cc=hch@lst.de \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-riscv@lists.infradead.org \
    --cc=palmer@sifive.com \
    --cc=paul.walmsley@sifive.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.