[PATCH V2 1/2] riscv: Add RISC-V svpbmt extension

[Atish Patra]

On Mon, Sep 27, 2021 at 1:53 PM Greg Favor <gfavor at ventanamicro.com> wrote:
>
> With the big caveat that I haven't been in the middle of this discussion, it seems like Allwinner D1's changes represent a custom (and nonconforming) extension.

As per the v1.12 privilege specification, bit 63 is reserved for
Svnapot extension while bit 60–54 are reserved for future standard
use.
D1's implementation uses both 60 and 63 bit for their custom "PBMT"
extension in addition to bit 61 & 62 [1].

> Isn't this just a matter of the patch needing to be treated as for a RISC-V custom extension per the recently clarified policy for handling upstreaming/etc. of custom extensions?  (Philipp can > speak to this clarified policy.)  Or what am I missing?

Linux kernel upstream policy is yet to adopt that clarification as it
was recently discussed at RVI meetings. Is there a written definition
of non-conforming/custom/incompatible ?
Moreover, as per the platform specification[2],

A non-conforming extension that conflicts with a supported standard
extensions must satisfy at least one of the following:
  --- It must be disabled by default.
  --- The supported standard extension must be declared as unsupported
in all feature discovery structures used by software.
      This option is allowed only if the standard extension is not required.

In this case, the custom non-conforming implementation can not be
disabled or marked unsupported as it is critical for all the necessary
I/O devices (usb, mmc, ethernet).
Without this custom implementation support in upstream, we can not
really use the mainline kernel for Allwinner D1.

[1] https://linuxplumbersconf.org/event/11/contributions/1100/attachments/841/1607/What%E2%80%99s%20the%20problem%20with%20D1%20Linux%20upstream-.pdf
[2] https://github.com/riscv/riscv-platform-specs/blob/main/riscv-platform-spec.adoc#2112-general

>
> Greg
>
> On Mon, Sep 27, 2021 at 1:14 PM Atish Patra <atishp at atishpatra.org> wrote:
>>
>> > @Palmer Dabbelt @Guo Ren
>> >
>> > Can we first decide what to do with D1's upstreaming plan ? I had a slide[1] to discuss that during RISC-V BoF.
>> > But we ran out of time. Let's continue the discussion here.
>> >
>> > We all agree that Allwinner D1 has incompatible changes with privilege specification because it uses two reserved bits even after Svpbmt is merged.
>> > Let's not argue on the reasoning behind this change. The silicon is already out and the specification just got frozen.
>> > Unfortunately, we don't have a time stone to change the past ;).
>> >
>> > We need to decide whether we should support the upstream kernel for D1. Few things to consider.
>> > – Can it be considered as an errata ?
>> > – Does it set a bad precedent and open can of worms in future ?
>> > – Can we just ignore D1 given the mass volume ?
>> >
>> > One solution I can think of is that we allow this as an exception to the patch acceptance policy.
>> > We need to explicitly specify this board as an exception because the policy was not in place during the design phase of the hardware.
>> > At least, it protects us from accepting the incompatible changes in the future. Any other ideas ?
>> >
>> > [1] https://linuxplumbersconf.org/event/11/contributions/1128/attachments/846/1757/RISC-V%20Bof.pdf



-- 
Regards,
Atish