Vector on Banana Pi BPI-F3

[Conor Dooley]

Yo,

On Mon, Jul 01, 2024 at 11:08:31AM +0200, Robbin Ehn wrote:
> There seems to be a large interest in running openjdk with vector on
> this board out-of-the-box.
> The vendor kernel have vector from 6.4 back-ported without hwprobe.
> And FYI: the vendor kernel for k230 has THEAD vector patches.
> Both do the right thing during context switches (sources have been checked).
> 
> It seems like we have three options, anymore?
> 
> A:
> Keep what we do: i.e. no hwprobe no V.
> Downside no V (default) on contemporary boards.
> Hence no V coverage in CI testing and disappointed early adopters.

Upside: pressure on vendors not to ship old, heavily modified kernels.
I'd be pretty vociferous about pushing the blame on the vendors were I
in your shoes! There's some work in progress for mainline spacemit k1
support that would allow you to get something usable for CI although
obviously these things move slowly. Palmer did mention that if this
board is helpful for compiler testing that some of the Rivos folks might
work on support for it in mainline though, which would be neat...

> B:
> Enable it for triplet mvendorid/marchid/mimplid.
> Only V for this specific board, other boards and/or updates to this
> board require new binaries.

And, depending on implementation, may break if the kernel running on the
board doesn't support vector. You'd need to check hwcap and the triplet.
m*id all come from the CPU, so you can't be sure that the values there
will uniquely identify a specific board or SoC for you anyway. If you
want to support the can of worms you're opening there with m*id stuff
for vendor kernels, then go for it. If you start it for vector on one
board, where do you draw a line in terms of either extension or boards?

> C:
> Enable it for boards with V in hwcap.
> Downside boards false reporting V (1.0), such as K230 small-CPU and THEAD,

Why does the small K230 CPU falsely report that? Does it have no vector
and report that it does? Or does it support 0.7 like the other T-head
stuff? I suppose the latter given they the patches you say their kernel
has.

One thing that we did in the kernel was, when parsing a devicetree, to
ignore v in riscv,isa where the CPU vendor was T-Head and the archid was
0x0. It wasn't meant to be a perfect detection of incorrect devicetrees,
but a simple best-effort attempt to handle vendor provided dtbs for
Vector 0.7 devices. Best-effort is fine in this case, cos ultimately it
isn't the kernel's problem if someone has incorrectly described their
hardware. Guo Ren claimed that no vector 1.0 devices have a 0x0 marchid,
but I do not know if there are vector 0.7 devices with a non-zero marchid.

I'd be very curious as to what the small cpu reports for marchid/mimpid,
to see if that rule would still hold true. If they happens to be non-zero,
mainline wouldn't even run on it, even ignoring vector, without either an
OpenSBI and devicetree replacement or kernel changes, so the courtesy
disabling of vector wouldn't even trigger. What it would mean, is a
similar approach to disable vector on 0.7 devices wouldn't suffice for
you.

> needs to be handled, safe fetch vsetvli and vsetvli v1.0 check can fix
> those two examples.
> If we miss a board or a new board comes out we may lack proper check thus crash.

With my only mainline matters blinkers on, that's another tick in the
"pressure on vendors to not ship old, heavily modified kernels" box!

> In PRs:
> https://github.com/openjdk/jdk/pull/19472
> https://github.com/openjdk/jdk/pull/19679
> 
> Options A was used.
> 
> The question is if we can reconsider due to the benefits and use
> another option allowing V to automatically work?

I think whether you reconsider isn't really a topic for lkml, it seems
more like a policy decision for your project as there's not a magic bullet
we can offer you that can be sure not to break if you intent supporting
"random" vendor kernels.

Cheers,
Conor.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 228 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-riscv/attachments/20240701/e8a1039d/attachment.sig>