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

[Christian Borntraeger <borntraeger@de.ibm.com>]

On 16.05.19 15:35, Collin Walling wrote:
> On 5/14/19 5:30 AM, Cornelia Huck wrote:
>> On Tue, 14 May 2019 11:27:32 +0200
>> David Hildenbrand <david@redhat.com> wrote:
>>
>>> On 14.05.19 11:25, Christian Borntraeger wrote:
>>>>
>>>>
>>>> On 14.05.19 11:23, Christian Borntraeger wrote:
>>>>>
>>>>>
>>>>> On 14.05.19 11:20, David Hildenbrand wrote:
>>>>>> On 14.05.19 11:10, Christian Borntraeger wrote:
>>>>>>>
>>>>>>>
>>>>>>> On 14.05.19 10:59, David Hildenbrand wrote:
>>
>>>>>>>> We can
>>>>>>>>
>>>>>>>> 1. Fail to start with #cpus > 240 when diag318=on
>>>>>>>> 2. Remove the error once we support more than one SCLP response page
>>>>>>>>
>>>>>>>> Or
>>>>>>>> b
>>>>>>>> 1. Allow to start with #cpus > 240 when diag318=on, but indicate only
>>>>>>>>     240 CPUs via SCLP
>>>>>>>> 2. Print a warning
>>>>>>>> 3. Remove the restriction and the warning once we support more than one
>>>>>>>>     SCLP response page
>>>>>>>>
>>>>>>>> While I prefer the second approach (similar to defining zPCI devices
>>>>>>>> without zpci=on), I could also live with the first approach.
>>>>>>>
>>>>>>> I prefer approach 1.
>>>>>>>   
>>>>>>
>>>>>> Isn't approach #2 what we discussed (limiting sclp, but of course to 247
>>>>>> CPUs), but with an additional warning? I'm confused.
>>>>>
>>>>> Different numbering interpretion. I was talking about 1 = "Allow to start with #cpus > 240 when diag318=on, but indicate only
>>>>> 240 CPUs via SCLP"
>>>>
>>>> So yes, variant 2 when I use your numbering. The only question is: do we need
>>>> a warning? It probably does not hurt.
>>>
>>> After all, we are talking about 1 VCPU that the guest can only use by
>>> indirect probing ... I leave that up to Collin :)
>>
>> I'd prefer a warning... even if it is a corner case, I think it's
>> better to be explicit instead of silent.
>>
> 
> Thanks for the discussion. I'll implement diag318 as a CPU feature again
> and adjust the max_cpu handling (to 247 now instead of 240).

Well, max cpu is 248, we decided to just not report cpus > 247 to the guest via
sclp.
> 
> Question: should diag318 be enabled by default for current CPU models?
> What should we do in the case where diag318=on but KVM does not support
> handling?

Lets keep it in the full model for now. we can change that later on.
> 
> I am not familiar with how close QEMU and KVM versions stay in sync.