linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Troy Benjegerdes <troy.benjegerdes@sifive.com>
To: Atish Patra <Atish.Patra@wdc.com>
Cc: "hch@lst.de" <hch@lst.de>,
	"paul.walmsley@sifive.com" <paul.walmsley@sifive.com>,
	"linux-riscv@lists.infradead.org"
	<linux-riscv@lists.infradead.org>,
	Damien Le Moal <Damien.LeMoal@wdc.com>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	"palmer@sifive.com" <palmer@sifive.com>
Subject: Re: [PATCH 15/15] riscv: disable the EFI PECOFF header for M-mode
Date: Wed, 21 Aug 2019 10:54:44 -0700	[thread overview]
Message-ID: <F4C28F0F-7385-432E-A766-64A3F8B8C381@sifive.com> (raw)
In-Reply-To: <4f1677e24a5fcdfd2fda714cdd66f4dbe7817284.camel@wdc.com>



> On Aug 21, 2019, at 10:31 AM, Atish Patra <Atish.Patra@wdc.com> wrote:
> 
> On Tue, 2019-08-20 at 21:14 -0700, Troy Benjegerdes wrote:
>>> On Aug 13, 2019, at 8:47 AM, Christoph Hellwig <hch@lst.de> wrote:
>>> 
>>> No point in bloating the kernel image with a bootloader header if
>>> we run bare metal.
>> 
>> I would say the same for S-mode. EFI booting should be an option, not
>> a requirement. 
> 
> EFI booting is never a requirement on any board. When EFI stub will be
> added for kernel, it will be enabled with CONFIG_EFI_STUB only. 
> 
> The current additional header is only 64 bytes and also required for
> booti in U-boot. So it shouldn't disabled for S-mode.
> 
> Disabling it for M-Mode Linux is okay because of memory constraint and
> M-Mode linux won't use U-boot anyways.
> 
>> I have M-mode U-boot working with bootelf to start BBL,
>> and at some point, I’m hoping we can have a M-mode linux kernel be
>> the SBI provider for S-mode kernels, 
> 
> Why do you want bloat a M-Mode software with Linux just for SBI
> implementation?
> 
> Using Linux as a last stage boot loader i.e. LinuxBoot may make sense
> though.
> 

Boot time, and ease of development, and simplified system management.

Having M-mode linux as a supervisor/boot kernel can get us to responding
to HTTPS/SSH/etc requests within seconds of power-on, while the ‘boot’
kernel can be loading guest S-mode kernels from things like NVME flash
drives that are going to be a lot more code and development to support in
U-boot or any other non-linux dedicated boot loader.

There’s also a very strong security argument, as Linux is going to get the
largest and broadest security review, and will likely get software updates
a lot faster than dedicated boot firmwares will.

Another reason would be sharing the same kernel binary (elf file) for both
M-mode, and S-mode, and using the device tree passed to each to specify
which mode it should be running it. There are probably a bunch of gotchas
with this idea, and even so I suspect someone will decide to go ahead and
just do it eventually because it could make testing, validation, and security
updates a lot easier from an operational/deployment point of view.

Linuxbios convinced me that if you want to do a really large cluster,
you can build, manage, and run such a thing with fewer people and
engineering cost than if you have all these extra layers of boot firmware
that require some company to have firmware engineers and lots of extra
system testing on the firmware.

  reply	other threads:[~2019-08-21 17:54 UTC|newest]

Thread overview: 47+ 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 ` [PATCH 01/15] irqchip/sifive-plic: set max threshold for ignored handlers Christoph Hellwig
2019-08-13 17:44   ` Paul Walmsley
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 16:36   ` Paul Walmsley
2019-08-13 16:42     ` Christoph Hellwig
2019-08-13 16:51       ` 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-14  4:41   ` Paul Walmsley
2019-08-19 10:18     ` 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 ` [PATCH 05/15] riscv: improve the default power off implementation Christoph Hellwig
2019-08-13 15:47 ` [PATCH 06/15] riscv: provide a flat entry loader 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 ` [PATCH 08/15] riscv: provide native clint access for M-mode Christoph Hellwig
2019-08-13 16:29   ` Mark Rutland
2019-08-19 10:16     ` Christoph Hellwig
2019-08-27 23:37       ` Palmer Dabbelt
2019-08-28  6:11         ` Christoph Hellwig
2019-09-03 18:48           ` Palmer Dabbelt
2019-09-04  2:05             ` Alan Kao
2019-08-21  0:24   ` Atish Patra
2019-08-21  0:42     ` hch
2019-08-13 15:47 ` [PATCH 09/15] riscv: implement remote sfence.i natively " Christoph Hellwig
2019-08-20 21:04   ` Atish Patra
2019-08-13 15:47 ` [PATCH 10/15] riscv: poison SBI calls " Christoph Hellwig
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 ` [PATCH 12/15] riscv: use the correct interrupt levels " Christoph Hellwig
2019-08-13 15:47 ` [PATCH 13/15] riscv: clear the instruction cache and all registers when booting Christoph Hellwig
2019-08-14  1:00   ` Alan Kao
2019-08-14  1:07     ` Alan Kao
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 ` [PATCH 15/15] riscv: disable the EFI PECOFF header for M-mode Christoph Hellwig
2019-08-20 21:07   ` Atish Patra
2019-08-21  4:14   ` Troy Benjegerdes
2019-08-21  7:12     ` Christoph Hellwig
2019-08-21 17:31     ` Atish Patra
2019-08-21 17:54       ` Troy Benjegerdes [this message]
2019-08-21 23:02         ` Anup Patel
2019-08-21 23:32           ` Troy Benjegerdes
2019-10-17 17:37 RISC-V nommu support v5 Christoph Hellwig
2019-10-17 17:37 ` [PATCH 15/15] riscv: disable the EFI PECOFF header for M-mode Christoph Hellwig
2019-10-18  3:06   ` Anup Patel

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=F4C28F0F-7385-432E-A766-64A3F8B8C381@sifive.com \
    --to=troy.benjegerdes@sifive.com \
    --cc=Atish.Patra@wdc.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 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).