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

[Conor Dooley <conor@kernel.org>]

[-- Attachment #1.1: Type: text/plain, Size: 5325 bytes --]

Hey!

Just bringing this up somewhere a bit more visible than the weekly pw
sync-up yoke!
I just got my VisionFive2 today & I see Heiko has just posted another
version of Zbb support series, right as I had started typing this in
fact, so I'm curious where we stand. There's gonna be quite a few
people with Zba/Zbb capable hardware soon by the looks of things, so
it'd be nice to have something we can point people at that actually
applies to recent kernels.

I know Palmer you said you'd do some work on it over Christmas, but
since that didn't materialise - are you still planning on spinning up a
v2?
Some thoughts on Drew's sysfs suggestion below would probably be useful
if you aren't.

Thanks,
Conor.





On Thu, Dec 01, 2022 at 05:06:14PM +0100, Andrew Jones wrote:
> 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

[-- Attachment #1.2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]

[-- Attachment #2: Type: text/plain, Size: 161 bytes --]

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