Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20;
Date:   Thu, 10 Mar 2022 09:09:34 -0800 (PST)
Subject:     Re: [PATCH] riscv: Work to remove kernel dependence on the M-extension
In-Reply-To: <CAK8P3a3mzax-OiaxBcxM_RgKNsd6N8HW0odRmw38u2jKE5aYaQ@mail.gmail.com>
CC:     Arnd Bergmann <arnd@arndb.de>, michael@michaelkloos.com,
        Paul Walmsley <paul.walmsley@sifive.com>,
        aou@eecs.berkeley.edu, linux-riscv@lists.infradead.org,
        linux-kernel@vger.kernel.org
From:   Palmer Dabbelt <palmer@dabbelt.com>
To:     Arnd Bergmann <arnd@arndb.de>
Message-ID: <mhng-3e1f2147-7acb-4dd7-8fce-41ec72def1d7@palmer-ri-x1c9>
Mime-Version: 1.0 (MHng)
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 8bit
Precedence: bulk

On Wed, 09 Mar 2022 23:54:17 PST (-0800), Arnd Bergmann wrote:
> On Thu, Mar 10, 2022 at 8:34 AM Palmer Dabbelt <palmer@dabbelt.com> wrote:
>> On Wed, 09 Mar 2022 02:02:27 PST (-0800), Arnd Bergmann wrote:
>> > On Wed, Mar 9, 2022 at 6:28 AM Michael T. Kloos <michael@michaelkloos.com> wrote:
>>
>> That'd be wonderful, but unfortunately we're trending the other way --
>> we're at the point where "words in the specification have meaning" is
>> controversial, so trying to talk about which flavors of the
>> specification are standard is just meaningless.  I obviously hope that
>> gets sorted out, as we've clearly been pointed straight off a cliff for
>> a while now, but LMKL isn't the place to have that discussion.  We've
>> all seen this before, nobody needs to be convinced this leads to a mess.
>>
>> Until we get to the point where "I wrote 'RISC-V' on that potato I found
>> in my couch" can be conclusively determined not compliant with the spec,
>> it's just silly to try and talk about what is.
>
> I would argue that codifying the required extensions through kernel source

The problem here isn't the required extensions, it's that vendors can 
claim to implement an extension on hardware that doesn't exhibit any of 
the behavior the specification expresses that systems with those 
extensions must have.  The D1 is a very concrete example of this.

> code is much stronger than interpreting a specification. Ideally the
> specification
> would match what the kernel requires, but it's not the end of the world if
> the kernel ends up making decisions that are different: If Linux can do
> runtime detection of non-M, non-A or pre-standard extensions and handle
> them correctly without a notable performance impact, it can do that. Or
> Linux could end up requiring things that are normally there but not
> in the scope of the spec.
>
> Regardless of who determines what the compatible subset is, I think there
> is value in splitting out Kconfig options that prevent booting on normal
> RV64GC machines (XIP, NOMMU, 32-bit, ...). This would probably
> not include the non-M option, as long as a non-M kernel works as
> expected on CPUs with the M instructions.

I get the value to having an option hiding these things, as users might 
shoot themselves in the foot.  I sent a patch, not sure it's exactly 
what we want but at least it's something concrete to discuss.