On 9/30/26 20:32, Stian Halseth wrote:
Hi all,
QEMU doesn't implement the SPARC crypto instructions, so the kernel's
crypto tests cannot execute optimized SPARC code.
See this issue[1] raised by Eric Biggers.
I became involved in this after submitting a patch[2] for native SPARC
XTS support. Since the kernel devs currently have no way of testing
this, outside of real hardware, the motivation is to make this possible
with the help of QEMU.
I've done some reading into the QEMU code, and might be able to
contribute an implementation.
Before investing time in it, I would appreciate some feedback from the
maintainers.
I'm thinking about adding a "crypto" CPU feature to sun4u which enables
the missing instructions.
Why sun4u and not sun4v? Because it would allow a direct -kernel image
boot without the OpenSPARC firmware, which QEMU doesn't ship.
This would mean adding SPARC T4(+) instructions on sun4u CPU models.
This combo does not really exist, so I want to know if that is
acceptable, or if you would rather have this done differently.
Since the kernel currently learns about the instructions from the sun4v
machine description's hwcap-list, a small kernel patch would be
required to read a hwcap-list property from the OF CPU node instead.
OpenBIOS could set that property for a CPU that has the feature.
If this is not desirable, it can also be implemented for sun4v with
OpenSPARC firmware. Kernel developers would need that firmware and a
boot disk image, since niagara cannot boot with -kernel.
I have a T4-1 and a T7-1 (M7) to check the instructions against.
[1] https://github.com/sparclinux/issues/issues/77
[2] https://lore.kernel.org/all/[email protected]/
Looking forward to hearing your thoughts,
When I implemented the VIS{3,4} stuff a couple of years ago, I tried to
add a newer cpu (though I forget which model). I couldn't get a kernel
to boot with that and sun4u, so in the end I left the cpu out and left
the extensions as plain cpu features.
The biggest problem with sun4v is that it's incomplete. It has the most
promise as an emulation platform because it is explicitly a hypervisor
platform. In the ideal case, QEMU would not faithfully model the
hardware, but would instead model the hypervisor interface. Which would
make lots of stuff far easier and quicker to emulate -- most notably the
TLB.
But it's a big packet of work and no one has done it.
r~
