Re: [sw-dev] SBI extension proposal v2

From: Alexander Graf <agraf@suse.de>
To: ron minnich <rminnich@gmail.com>
Cc: "mark.rutland@arm.com" <mark.rutland@arm.com>,
	Christoph Hellwig <hch@infradead.org>,
	Damien Le Moal <Damien.LeMoal@wdc.com>,
	Olof Johansson <olof.johansson@gmail.com>,
	"alankao@andestech.com" <alankao@andestech.com>,
	"abner.chang@hpe.com" <abner.chang@hpe.com>,
	Benjamin Herrenschmidt <benh@kernel.crashing.org>,
	Palmer Dabbelt <palmer@sifive.com>,
	"zong@andestech.com" <zong@andestech.com>,
	Atish Patra <atish.patra@wdc.com>,
	"sw-dev@groups.riscv.org" <sw-dev@groups.riscv.org>,
	Paul Walmsley <paul.walmsley@sifive.com>,
	Anup Patel <anup@brainfault.org>,
	"mick@ics.forth.gr" <mick@ics.forth.gr>,
	Alistair Francis <Alistair.Francis@wdc.com>,
	Luke Kenneth Casson Leighton <lkcl@lkcl.net>,
	"linux-riscv@lists.infradead.org"
	<linux-riscv@lists.infradead.org>,
	Andrew Waterman <andrew@sifive.com>
Subject: Re: [sw-dev] SBI extension proposal v2
Date: Mon, 28 Jan 2019 21:37:49 +0100	[thread overview]
Message-ID: <e67df6aa-b850-4c92-6b52-5be6cbecfffa@suse.de> (raw)
In-Reply-To: <CAP6exYJttZXUp=NAikvQ-9Orj-Ptpj4=Pnj30GN90Rzt_Rvvyg@mail.gmail.com>

On 28.01.19 21:18, ron minnich wrote:
> On Mon, Jan 28, 2019 at 11:55 AM Alexander Graf <agraf@suse.de> wrote:
> 
>> You're mixing up 2 things (which is a pretty common fallacy I've come
>> across people who worked too much with x86 firmware): Design and
>> implementation.
> 
> uhm, alex, I worked on or started the coreboot ports to
> arm
> arm64
> ppc
> riscv
> alpha
> 
> I've been working on various non-x86 firmware for over 40 years,
> starting in 8 bit days.

I know.

> You should probably not assume too much about people.
> 
>> The conclusion that runtime firmware is a bad idea IMHO is wrong though.
> 
> We can agree to disagree. But please don't start by stating things
> about my background; you don't know me and you're wrong.

I'm fairly sure you know me about as well as I do know you ;).

> Runtime firmware is acceptable *if and only if* the kernel can measure
> it, disable it all or in part, or replace it.
> That's a different statement than what you just said. I don't like

Hm. Ok, it depends on your deployment model of course. I tend to agree
that runtime firmware should be an OS triggered interface. If the OS
doesn't ask it to do something, it shouldn't.

The big problem is when only firmware has the rights to do something and
you need to trust it. That brings us back to this discussion.

So yes, you can "disable" it, but not replace it. So you may lose
functionality if you choose not to call firmware.

The ususal answer I would have to that is to empower system owners to
build their own firmware (which allows them to replace bits), but I can
see how that doesn't always work for every case. I don't have a good
answer yet, but I'm sure there will be discussions at FOSDEM about it.

> runtime firmware, but of course on RISCV there are few options
> for some registers. But it is a very rare runtime firmware that is
> implemented correctly or even well.
> 
> There is one company that is so concerned about M mode they are
> implementing a RISCV CPU without it.
> 
>> Now, if the firmware development model is so broken but at the same time
>> such firmware gives us the ability to abstract interfaces better, what
>> is the solution?
> 
> you give me the information I need to write a driver. Done. That's
> known to work. And for linuxboot systems, that's the only way it
> works.That way, we have one driver to deal with, not two. Server
> systems that work this way are being deployed today.

Sweet. What if you want to support 10000 different types of servers? You
write one (or many) driver(s) each?

>> You obviously need to apply the same standards as you do for the OS to
>> firmware. It's why open firmware is so important.
> 
> Sure. It'd be nice if that worked, but it's essential to ensure it's
> the only thing that works. It's important not to enable architecture
> features that can be used to make open source firmware
> difficult or impossible. PMP is one such feature, since it allows
> firmware to lock down regions of memory and make them inaccessible to
> the kernel.
> 
> In general, however, vendor firmware is extremely poorly written, and
> I don't expect that to change.
> 
>> But putting everything into Linux instead really is not the answer. The
>> only thing it does is break forward compatibility and bloat code size.
> 
> I am, today, fitting a linux kernel and full Go userland into about 3M
> in SPI. For reference, this is smaller than the audio codec firmware
> on some chipsets.

Does that same kernel run on all the 10000 different types of servers I
mentioned above?

The problem is not to build something for *one* configuration, it's how
we can abstract pieces well enough so that we can have a single system
image that runs on any system you throw it at.

> I don't agree with your claim.
> 
> That said, RISCV will have the SBI, and there is no getting around it
> for certain purposes, but there's no reason to encourage growth.

At least here we do agree (mostly) :).

Alex

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