On Mon, Jun 22, 2026 at 05:05:28PM +0200, Harald Freudenberger wrote:
> On 2026-06-18 07:57, Finn Callies wrote:
> > On 17.06.26 11:48, Harald Freudenberger wrote:
> > > index d3e69aaca6..71e0e41d6e 100644
> > > --- a/target/s390x/gen-features.c
> > > +++ b/target/s390x/gen-features.c
> > > @@ -924,6 +924,9 @@ static uint16_t qemu_MAX[] = {
> > > S390_FEAT_KM_AES_128,
> > > S390_FEAT_KM_AES_192,
> > > S390_FEAT_KM_AES_256,
> > > + S390_FEAT_KM_EAES_128,
> > > + S390_FEAT_KM_EAES_192,
> > > + S390_FEAT_KM_EAES_256,
> >
> > I would strongly prefer PAES instead of EAES. I know the CPACF
> > function is called KM...ENCRYPTED...AES... but since we use protected
> > or PAES in any other context and never Encrypted AES I would highly
> > suggest PAES here as well. Or as an alternative expand the E to
> > S390_FEAT_KM_ENCRYPTED_AES_128 to match the CPACF naming.
> >
>
> Yes, I am with you. But this is not part of this patch series.
> These defines have been introduced into qemu long before this patch.
> Maybe someone could rework them but not here and now with this patch
> series.
They have been introduced with the CPU model for the hardware model
that introduced those. Naming should not change as we would run
into the difference for the cpu feature itself:
DEF_FEAT(KM_EAES_128, "km-eaes-128", KM, 26, "KM Encrypted-AES-128")
The "km-eaes-128" indication is actually the visible/external part
of the CPU model.
