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

From: Nick Kossifidis
Date: Mon Sep 27 2021 - 21:02:20 EST


Στις 2021-09-27 23:13, Atish Patra έγραψε:
We need to decide whether we should support the upstream kernel for D1. Few things to consider.
– Can it be considered as an errata ?

It's one thing to follow the spec and have an error in the implementation, and another to not follow the spec.

– Does it set a bad precedent and open can of worms in future ?

IMHO yes, I'm thinking of Kendryte 210 devs for example coming up and asking for MMU support, they 've also shipped many chips already. I can also imagine other vendors in the future coming up with implementations that violate the spec in which case handling the standard stuff will become messy and complex, and hurt performance/security. We'll end up filling the code with exceptions and tweaks all over the place. We need to be strict about what is "riscv" and what's "draft riscv" or "riscv inspired", and what we are willing to support upstream. I can understand supporting vendor extensions upstream but they need to fit within the standard spec, we can't have for example extensions that use encoding space/csrs/fields etc reserved for standard use, they may only use what's reserved for custom/vendor use. At least let's agree on that.

– Can we just ignore D1 given the mass volume ?


IMHO no, we need to find a way to support it upstream but I believe there is another question to answer:

Do we also guarantee "one image to rule them all" approach, required by binary distros, for implementations that violate the spec ? Are we ok for example to support Allwinner D1 upstream but require a custom configuration/build instead of supporting it with the "generic" image ? In one case we need to handle the violation at runtime and introduce overhead for everyone (like looking up __riscv_svpbmt every time we set a PTE in this case), in the other it's an #ifdef.

Regards,
Nick