Re: [PATCH v3] s390/kvm: fix diag318 propagation and reset functionality

[Thomas Huth]

On 24/11/2020 19.14, Christian Borntraeger wrote:
> 
> 
> On 24.11.20 18:58, Collin Walling wrote:
>> On 11/24/20 11:51 AM, Thomas Huth wrote:
>>> On 24/11/2020 17.26, Collin Walling wrote:
>>>> On 11/24/20 8:04 AM, Christian Borntraeger wrote:
>>>>>
>>>>> On 24.11.20 13:48, Christian Borntraeger wrote:
>>>>>> Now that we have this - fully implemented in QEMU - shouldnt
>>>>>> we add els and diag318 also to the default CPU models?
>>>>>
>>>>> At least the extended SCCB should be fine to be enabled all the 
>>>>> time.
>>>>>
>>>>
>>>> Yeah ELS should be fine to default-enable since it's handled entirely
>>>> via QEMU. If the kernel can support it, great. If not, then the kernel
>>>> will simply provide the original 4K SCCB.
>>>>
>>>> DIAG318 requires KVM support, so I do not think we should default-enable
>>>> that one :)
>>>
>>> Ok, but does ELS have any advantages as long as you don't use diag318? If we
>>> do not enable diag318 by default, what sense does it make to enable ELS by
>>> default?
>>>
>>>  Thomas
>>>
>>>
>>
>> One immediate benefit is that it would make configuring a guest to
>> enable diag318 require one less step. Right now, the VM must explicitly
>> enable both ELS *and* diag318 in order to use the latter feature. With
>> ELS default-enabled, the user would only have to explicitly enable
>> diag318 if they want it.

Ok, fair point.

> And it would allow to go beyond 248 CPUs. But since we are already late in 
> 5.2, 
> we can defer this to the next QEMU I guess.

Ah, ok, so ELS is enough for getting more than 248 CPUs? Good to know, I
somehow expected that some additional magic would be required for this.

Ok, then it makes sense to enable it by default in the full model, but I
think it's too late for 5.2 now, indeed, so that's rather something for the
next release.

 Thomas