Booting kernel (4.20-rc1) with riscv-pk @
6ebd0f2a46255d0c76dad3c05b16c1d154795d26 (master/HEAD) on Fedora 29 one gets:
[..]
[ 55.075000] unsupported ISA "rv64imafdcsu" in device tree
[ 55.075000] unsupported ISA "rv64imafdcsu" in device tree
[ 55.076000] unsupported ISA "rv64imafdcsu" in device tree
[ 55.076000] unsupported ISA "rv64imafdcsu" in device tree
[ 55.077000] systemd[1]: Detected architecture riscv64.
[..]
The patch adds the missing S and U modes.
Signed-off-by: David Abdurachmanov <[email protected]>
---
arch/riscv/kernel/cpu.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/riscv/kernel/cpu.c b/arch/riscv/kernel/cpu.c
index 3a5a2ee31547..4029c7e6872b 100644
--- a/arch/riscv/kernel/cpu.c
+++ b/arch/riscv/kernel/cpu.c
@@ -64,7 +64,7 @@ int riscv_of_processor_hartid(struct device_node *node)
static void print_isa(struct seq_file *f, const char *orig_isa)
{
- static const char *ext = "mafdc";
+ static const char *ext = "mafdcsu";
const char *isa = orig_isa;
const char *e;
--
2.19.1
On 10.11.18 07:45, David Abdurachmanov wrote:
>
> The patch adds the missing S and U modes.
This is the same patch I submitted earlier (see v2 here [1], based on
Palmer's feedback). Palmer stated that the "S" extension should not be
exposed to usermode.
Since two people arrived at the same solution, I wonder if the
supervisor mode should really be hidden from userspace, as it's about
the CPU information, not about the environment the calling code is
running as.
[1] https://lkml.org/lkml/2018/11/10/96
Patrick
On Sat, 10 Nov 2018 00:35:15 PST (-0800), [email protected] wrote:
> On 10.11.18 07:45, David Abdurachmanov wrote:
>>
>> The patch adds the missing S and U modes.
>
> This is the same patch I submitted earlier (see v2 here [1], based on
> Palmer's feedback). Palmer stated that the "S" extension should not be
> exposed to usermode.
>
> Since two people arrived at the same solution, I wonder if the
> supervisor mode should really be hidden from userspace, as it's about
> the CPU information, not about the environment the calling code is
> running as.
>
> [1] https://lkml.org/lkml/2018/11/10/96
I still think S should be hidden from applications. This patch was fairly
mechanical, so it probably just wasn't though about twice -- that's the problem
with user ABI stuff, lots of times the obvious answer isn't the correct one :).
I'll take your second patch, I just haven't gotten around to actually fully
reviewing patches yet as I'm still in my email triage phase.
Thanks!
On Sun, Nov 11, 2018 at 11:14 PM Palmer Dabbelt <[email protected]> wrote:
>
> On Sat, 10 Nov 2018 00:35:15 PST (-0800), [email protected] wrote:
> > On 10.11.18 07:45, David Abdurachmanov wrote:
> >>
> >> The patch adds the missing S and U modes.
> >
> > This is the same patch I submitted earlier (see v2 here [1], based on
> > Palmer's feedback). Palmer stated that the "S" extension should not be
> > exposed to usermode.
> >
> > Since two people arrived at the same solution, I wonder if the
> > supervisor mode should really be hidden from userspace, as it's about
> > the CPU information, not about the environment the calling code is
> > running as.
> >
> > [1] https://lkml.org/lkml/2018/11/10/96
>
> I still think S should be hidden from applications. This patch was fairly
> mechanical, so it probably just wasn't though about twice -- that's the problem
> with user ABI stuff, lots of times the obvious answer isn't the correct one :).
>
True. It was mechanical based on warnings I noticed while booting Fedora
with latest kernel and BBL.
Also true, that /proc/cpuinfo doesn't need to reveal all things to user space
(especially if you don't want various programs to depend on it as some
tend to parse /proc/cpuinfo).
Note, that on server systems which probably would implement SMBIOS
(based on the current proposal for RISC-V) the administrator could
check for S mode.