Re: [PATCH v6 2/2] s390: diagnose 318 info reset and migration support

[Collin Walling]

On 1/28/20 6:24 AM, Cornelia Huck wrote:
> On Mon, 27 Jan 2020 18:05:36 -0500
> Collin Walling <address@hidden> wrote:
> 
>> On 1/27/20 12:35 PM, Cornelia Huck wrote:
>>> On Mon, 27 Jan 2020 11:39:02 -0500
>>> Collin Walling <address@hidden> wrote:
>>>   
>>>> On 1/27/20 6:47 AM, Cornelia Huck wrote:  
>>>>> On Fri, 24 Jan 2020 17:14:04 -0500
>>>>> Collin Walling <address@hidden> wrote:
>>>>>     
>>
>> [...]
>>
>>>>>>
>>>>>> The availability of this instruction is determined by byte 134, bit 0
>>>>>> of the Read Info block. This coincidentally expands into the space used  
>>>>>>   
>>>>>
>>>>> "SCLP Read Info"
>>>>>     
>>>>>> for CPU entries by taking away one byte, which means VMs running with
>>>>>> the diag318 capability will not be able to retrieve information regarding
>>>>>> the 248th CPU. This will not effect performance, and VMs can still be
>>>>>> ran with 248 CPUs.    
>>>>>
>>>>> Are there other ways in which that might affect guests? I assume Linux
>>>>> can deal with it? Is it ok architecture-wise?
>>>>>
>>>>> In any case, should go into the patch description :)
>>>>>     
>>>>
>>>> Same as above. I'll try to provide more information regarding what happens
>>>> here in my next reply.  
>>>
>>> I think you can lift some stuff from the cover letter.
>>>   
>>
>> Here's what I found out:
>>
>> Each CPU entry holds info regarding the CPU's address / ID as well as an 
>> indication of the availability of certain CPU features. With these patches,
>> we lose a CPU entry for one CPU (essentially what would be the CPU at the
>> tail-end of the list). This CPU exists, but is essentially in limbo... the
>> machine cannot access any information regarding it.
> 
> s/machine/guest/ ?
> 

Correct.

>>
>> So, a VM can run with the original N max CPUs, but in reality we can only
>> utilize n-1. 
> 
> s/we/the guest/ ?
> 

Correct again.

> With those changes, it makes sense to put your explanations into the
> patch description (for later reference).
> 
>>
>>>>  
>>>>>>  
>>
>> [...]
>>
>>
> 
> 


-- 
Respectfully,
- Collin Walling