Re: [PATCH v1 0/5] RISC-V Hardware Probing User Interface

[Andrew Jones <ajones@ventanamicro.com>]

On Thu, Oct 13, 2022 at 09:35:46AM -0700, Palmer Dabbelt wrote:
> These are very much up for discussion, as it's a pretty big new user
> interface and it's quite a bit different from how we've historically
> done things: this isn't just providing an ISA string to userspace, this
> has its own format for providing information to userspace.
> 
> There's been a bunch of off-list discussions about this, including at
> Plumbers.  The original plan was to do something involving providing an
> ISA string to userspace, but ISA strings just aren't sufficient for a
> stable ABI any more: in order to parse an ISA string users need the
> version of the specifications that the string is written to, the version
> of each extension (sometimes at a finer granularity than the RISC-V
> releases/versions encode), and the expected use case for the ISA string
> (ie, is it a U-mode or M-mode string).  That's a lot of complexity to
> try and keep ABI compatible and it's probably going to continue to grow,
> as even if there's no more complexity in the specifications we'll have
> to deal with the various ISA string parsing oddities that end up all
> over userspace.
> 
> Instead this patch set takes a very different approach and provides a se
> of key/value pairs that encode various bits about the system.  The big
> advantage here is that we can clearly define what these mean so we can
> ensure ABI stability, but it also allows us to encode information that's
> unlikely to ever appear in an ISA string (see the misaligned access
> performance, for example).  The resulting interface looks a lot like
> what arm64 and x86 do, and will hopefully fit well into something like
> ACPI in the future.
> 
> The actual user interface is a syscall.  I'm not really sure that's the
> right way to go about this, but it makes for flexible prototying.
> Various other approaches have been talked about like making HWCAP2 a
> pointer, having a VDSO routine, or exposing this via sysfs. 

Hi Palmer,

To throw my two cents into the penny jar, I'd vote for sysfs. It handles
the heterogeneous CPU case since cpu feature nodes can be hung off each
cpu node. It also avoids yet another encoding. If we enumerate extensions
and their properties then we need to maintain that enumeration in both
the kernel space and userspace. If, OTOH, we use sysfs node names for
the encoding, then, when we match the spec naming exactly, e.g.

 .../features/zicbom
 .../features/zihintpause
 .../features/sscofpmf

userspace can look for features by name. Userspace libraries can even
lead the kernel in development, since the encoding (the spec name) is
already agreed.

Properties of extensions are just sub-nodes, some with standard names,
like

 .../features/zicbom/major
 .../features/zicbom/minor

and others, which are cpu feature specific, like

 .../features/zicbom/block_size

I used 'features' in the above examples for the node name, rather than
'isa', since not all features map to isa extensions, but it should be
possible to fit non-isa features into the same framework.

Thanks,
drew


> Those seem
> like generally reasonable approaches, but I've yet to figure out a way
> to get the general case working without a syscall as that's the only way
> I've come up with to deal with the heterogenous CPU case.  Happy to hear
> if someone has a better idea, though, as I don't really want to add a
> syscall if we can avoid it.
> 
> I threw this together during the conferences so I would be surprised if
> it's not broken, but I figured it'd be best to just get something on the
> lists sooner rather that later.  Happy to have someone go fix my code,
> but the new uABI is really going to be the tricky bit here.  There's
> some test code included, but I haven't even booted a kernel with these
> patches so YMMV.
> 
> These are also up at kernel.org/palmer/linux/riscv-hwprobe-v1 in case
> that's easier for folks.
> 
> 
> 
> _______________________________________________
> linux-riscv mailing list
> linux-riscv@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-riscv

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