Hi Mark,
On Sat, 2026-10-31 at 09:06 +0000, Mark Cave-Ayland wrote:
>
> I wonder if we need to make it more obvious via the property name that this
> is something that is not present on real hardware? As a lot of people use
> QEMU for testing SPARC installations, we should make sure that people
> understand this property is not expected to be present outside of an
> emulated environment.
>
Good point. I'll rename the property to "qemu,hwcap-list". That should follow
the usual vendor prefix for non-standard OF properties. I will also change the
OpenBIOS and kernel side to match.
I'm working on some other patches now, so I plan to ship this right away.
> > +static void fw_cfg_build_hwcap_list(FWCfgState *fw_cfg, SPARCCPU *cpu)
> > +{
> > + static const struct {
> > + uint32_t mask;
> > + const char *name;
> > + } capabilities[] = {
> > + { 0, "popc" },
> > + { CPU_FEATURE_FSMULD, "fsmuld" },
> > + { CPU_FEATURE_VIS1, "vis" },
> > + { CPU_FEATURE_VIS2, "vis2" },
> > + { CPU_FEATURE_FMAF, "fmaf" },
> > + { CPU_FEATURE_VIS3, "vis3" },
> > + { CPU_FEATURE_IMA, "ima" },
> > + { CPU_FEATURE_CRYPTO, "aes" },
> > + { CPU_FEATURE_CRYPTO, "sha1" },
> > + { CPU_FEATURE_CRYPTO, "sha256" },
> > + { CPU_FEATURE_CRYPTO, "sha512" },
> > + { CPU_FEATURE_CRYPTO, "crc32c" },
> > + };
>
> For the existing CPU features we have a direct mapping between the feature
> and the name, but for crypto it is split into individual instruction groups.
> Presumably this is because the crypto instruction implementation is
> incomplete?
The split itself comes from the hwcap-list format. A T4 lists each
group separately (aes, des, md5, sha256, crc32c and so on), and Linux
matches those names, with each driver then checking its CFR bit.
And yes, QEMU implements only some of the T4 groups: AES, SHA-1/256/512
and CRC32C. The list names exactly those, so it agrees with the CFR
value QEMU returns. I'll add a comment saying so in v2.
Thanks a lot for the review!
/Stian
signature.asc
Description: This is a digitally signed message part
