[PATCH v3 00/12] RISC-V: provide some accelerated cryptography implementations using vector extensions

[Palmer Dabbelt]

On Tue, 05 Dec 2023 23:41:55 PST (-0800), ebiggers at kernel.org wrote:
> Hi Jerry,
>
> On Wed, Dec 06, 2023 at 03:02:40PM +0800, Jerry Shih wrote:
>> On Dec 6, 2023, at 08:46, Eric Biggers <ebiggers at kernel.org> wrote:
>> > On Tue, Dec 05, 2023 at 05:27:49PM +0800, Jerry Shih wrote:
>> >> This series depend on:
>> >> 2. support kernel-mode vector
>> >> Link: https://lore.kernel.org/all/20230721112855.1006-1-andy.chiu@sifive.com/
>> >> 3. vector crypto extensions detection
>> >> Link: https://lore.kernel.org/lkml/20231017131456.2053396-1-cleger@rivosinc.com/
>> >
>> > What's the status of getting these prerequisites merged?
>> >
>> > - Eric
>>
>> The latest extension detection patch version is v5.
>> Link: https://lore.kernel.org/lkml/20231114141256.126749-1-cleger@rivosinc.com/
>> It's still under reviewing.
>> But I think the checking codes used in this crypto patch series will not change.
>> We could just wait and rebase when it's merged.
>>
>> The latest kernel-mode vector patch version is v3.
>> Link: https://lore.kernel.org/all/20231019154552.23351-1-andy.chiu@sifive.com/
>> This patch doesn't work with qemu(hit kernel panic when using vector). It's not
>> clear for the status. Could we still do the reviewing process for the gluing code and
>> the crypto asm parts?
>
> I'm almost ready to give my Reviewed-by for this whole series.  The problem is
> that it can't be merged until its prerequisites are merged.
>
> Andy Chiu's last patchset "riscv: support kernel-mode Vector" was 2 months ago,
> but he also gave a talk at Plumbers about it more recently
> (https://www.youtube.com/watch?v=eht3PccEn5o).  So I assume he's still working
> on it.  It sounds like he's also going to include support for preemption, and
> optimizations to memcpy, memset, memmove, and copy_{to,from}_user.

So I think we just got blocked on not knowing if turning on vector 
everywhere in the kernel was a good idea -- it's not what any other port 
does despite there having been some discussions floating around, but we 
never really figured out why.  I can come up with some possible 
performance pathologies related to having vector on in many contexts, 
but it's all theory as there's not really any vector hardware that works 
upstream (though the K230 is starting to come along, so maybe that'll 
sort itself out).

Last we talked I think the general consensus is that we'd waited long 
enough, if nobody has a concrete objection we should just take it and 
see -- sure maybe there's some possible issues, but anything could have 
issues.

> I think it would be a good idea to split out the basic support for
> kernel_vector_{begin,end} so that the users of them, as well as the preemption
> support, can be considered and merged separately.  Maybe patch 1 of the series
> (https://lore.kernel.org/r/20231019154552.23351-2-andy.chiu@sifive.com) is all
> that's needed initially?

I'm fine with that sort of approach too, it's certainly more in line 
with other ports to just restrict the kernel-mode vector support to 
explicitly enabled sections.  Sure maybe there's other stuff to do in 
kernel vector land, but we can at least get something going.

> Andy, what do you think?

I'll wait on Andy to see, but I generally agree we should merge 
something for this cycle.

Andy: maybe just send a patch set with what you think is the best way to 
go?  Then we have one target approach and we can get things moving.

> - Eric