On Tue, 05 Dec 2023 23:41:55 PST (-0800), ebiggers@xxxxxxxxxx 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@xxxxxxxxxx> 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@xxxxxxxxxx/
>> 3. vector crypto extensions detection
>> Link: https://lore.kernel.org/lkml/20231017131456.2053396-1-cleger@xxxxxxxxxxxx/
>
> 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@xxxxxxxxxxxx/
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@xxxxxxxxxx/
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@xxxxxxxxxx) 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
