On 02.05.20 07:15, Markus Armbruster wrote:
> Christian Borntraeger <borntrae...@de.ibm.com> writes:
>
>> On 29.04.20 10:54, Christian Borntraeger wrote:
>>>
>>>
>>> On 28.04.20 19:13, David Hildenbrand wrote:
>>>> On 28.04.20 18:34, Markus Armbruster wrote:
>>>>> Both s390_features[S390_FEAT_PCC_CMAC_AES_256].name and
>>>>> s390_features[S390_FEAT_PCC_CMAC_EAES_256].name is
>>>>> "pcc-cmac-eaes-256". The former is obviously a pasto.
>>>>>
>>>>> Impact:
>>>>>
>>>>> * s390_feat_bitmap_to_ascii() misidentifies S390_FEAT_PCC_CMAC_AES_256
>>>>> as "pcc-cmac-eaes-256". Affects QMP commands query-cpu-definitions,
>>>>> query-cpu-model-expansion, query-cpu-model-baseline,
>>>>> query-cpu-model-comparison, and the error message when
>>>>> s390_realize_cpu_model() fails in check_compatibility().
>>>>>
>>>>> * s390_realize_cpu_model() misidentifies it in check_consistency()
>>>>> warnings.
>>>>>
>>>>> * s390_cpu_list() likewise. Affects -cpu help.
>>>>>
>>>>> * s390_cpu_model_register_props() creates CPU property
>>>>> "pcc-cmac-eaes-256" twice. The second one fails, but the error is
>>>>> ignored (a later commit will change that). Results in a single
>>>>> property "pcc-cmac-eaes-256" with the description for
>>>>> S390_FEAT_PCC_CMAC_AES_256, and no property for
>>>>> S390_FEAT_PCC_CMAC_EAES_256. CPU properties are visible in CLI -cpu
>>>>> and -device, QMP & HMP device_add, QMP device-list-properties, and
>>>>> QOM introspection.
>>>>>
>>>>> Fix by deleting the wayward 'e'.
>>>>
>>>> Very nice catch - thanks!
>>>>
>>>> While this sounds very bad, it's luckily not that bad in practice
>>>> (currently).
>>>>
>>>> The feature (or rather, both features) is part of the feature group
>>>> "msa4". As long as we have all sub-features part of that group (which is
>>>> usually the case), we will always indicate "msa4" to the user, instead
>>>> of all the separate sub-features. So, expansion, baseline, comparison
>>>> will usually only work with "msa4".
>>>>
>>>> (in addition, current KVM is not capable of actually masking off these
>>>> sub-features, so it will still, always see the feature, even if not
>>>> explicitly specified via "-cpu X,pcc-cmac-aes-256=on)
>>>>
>>>> I think we should do stable backports.
>>>
>>> makes sense, but I would like to do some testing upfront (old QEMU <-> new
>>> QEMU
>>
>> So migration does work between a qemu with and without the patch for
>> host-model and
>> custom model=z14.
>
> Is this a Tested-by?
Yes. As David pointed out when a user really starts to pick manual things in
MSA4 then we
can have a non-migrateable guests. But this is still the right thing I guess.
