Re: [qemu-s390x] [PATCH v4] s390: diagnose 318 info reset and migration support

[David Hildenbrand]

On 13.05.19 11:34, Christian Borntraeger wrote:
> 
> 
> On 13.05.19 10:03, David Hildenbrand wrote:
>>>> +    if ((SCCB_SIZE - sizeof(ReadInfo)) / sizeof(CPUEntry) < S390_MAX_CPUS)
>>>> +        mc->max_cpus = S390_MAX_CPUS - 8;
>>>
>>> This is too complicated, just set it always to 240.
>>>
>>> However, I am still not sure how to best handle this scenario. One
>>> solution is
>>>
>>> 1. Set it statically to 240 for machine > 4.1
>>> 2. Keep the old machines unmodifed
>>> 3. Don't indicate the CPU feature for machines <= 4.0
>>>
>>> #3 is the problematic part, as it mixes host CPU features and machines.
>>> Bad. The host CPU model should always look the same on all machines. I
>>> don't like this.
>>>
>>
>> FWIW, #3 is only an issue when modeling it via the CPU model, like
>> Christian suggested.
>>
>> I suggest the following
>>
>> 1. Set the max #cpus for 4.1 to 240 (already done)
>> 2. Keep it for the other machines unmodified (as suggested by Thomas)
>> 3. Create the layout of the SCCB depending on the machine type (to be done)
>>
>> If we want to model diag318 via a CPU feature (which makes sense for
>> migration):
>>
>> 4. Disable diag318 with a warning if used with a machine < 4.1
>>
> 
> I think there is a simpler solution. It is perfectly fine to fail the startup
> if we cannot fulfil the cpu model. So lets just allow 248 and allow this 
> feature 
> also for older machines. And if somebody chooses both at the same time,
> lets fails the startup.

To which knob do you want to glue the layout of the SCLP response? Like
I described?  Do you mean instead of warning and masking the feature off
as I suggested, simply failing?

In that case, -machine ..-4.0 -cpu host will not work on new HW with new
KVM. Just noting.

-- 

Thanks,

David / dhildenb